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Abstract 


Organizations  struggle  with  many  problems  in  complex  systems  of  systems  for  which  solutions 
are  not  codified  or  even  conceived,  such  as  a  mutual  understanding  of  “common”  terms  and  con¬ 
cepts  across  participating  enterprises  and  the  lack  of  a  global  view  by  any  single  system-of- 
systems  participant.  System  and  software  purchasers  and  suppliers  need  a  different  set  of  ap¬ 
proaches  and  techniques  than  are  typically  in  use  today  to  satisfy  user  demands  that  reflect  turbu¬ 
lent  operational  environments.  Beyond  purchasers  and  engineers,  all  participants  in  a  complex, 
systems-of-systems  environment  need  a  different  set  of  perspectives  and  expectations  about  user 
demands  than  those  typical  in  product-centered  engineering.  The  SoS  Navigator  approach  pro¬ 
vides  leaders  participating  in  complex  systems  of  systems  with  ( 1 )  novel  insights  into  critical  as¬ 
pects  of  the  demand  and  supply  sides  of  their  situation  and  (2)  criteria  on  which  to  decide  whether 
their  systems-of-systems  context  requires  the  adoption  and  sustainment  of  a  different  business 
model  than  ones  that  are  typical  today.  This  technical  note  introduces  the  fundamental  concepts, 
processes,  and  techniques  of  the  evolving  SoS  Navigator  approach.  It  also  summarizes  case  stud¬ 
ies  that  illustrate  the  use  of  SoS  Navigator  processes  and  tools  in  healthcare,  military,  and  civilian 
government  systems-of-systems  contexts. 
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1  Background 


Over  the  past  decade,  there  has  been  a  significant  shift  in  the  way  in  which  information  technol¬ 
ogy  (IT)  systems  are  built  and  deployed.  The  development  of  individual,  standalone  systems  has 
decreased,  and  IT  software  systems  now  tend  to  be  designed,  developed,  and  fielded  with  the  ex¬ 
pectation  that  an  individual  system  will  be  a  part  of  a  larger  network  of  systems,  commonly 
termed  a  system  of  systems  [Miller  2001,  Singh  2007,  Beaudouin-Lafon  1999]. 

This  shift  toward  systems  of  systems  has  also  occurred  in  domains  other  than  IT.  For  instance,  the 
U.  S.  Department  of  Defense  (DoD)  is  now  moving  rapidly  toward  network-centric  operations,  in 
which  individual  weapons  systems  are  related  elements  in  a  global  web  of  systems.  In  the  finance, 
manufacturing,  healthcare,  and  service  industries,  network-based  computing  is  proliferating  as  is 
the  service-oriented  architecture  (SOA)  approach,  a  particular  architectural  style  defined  by  the 
OASIS  Reference  Model  as  “...a  paradigm  for  organizing  and  utilizing  distributed  capabilities 
that  may  be  under  the  control  of  different  ownership  domains”  [OASIS  2006]. 

The  tasks  of  designing  and  developing  software  in  such  a  context  are  considerably  different  from 
those  of  designing  and  developing  software  for  a  standalone  system.  Many  of  the  software  engi¬ 
neering  disciplines — such  as  requirements  engineering,  software  architecture,  testing,  mainte¬ 
nance,  and  support — are  significantly  changed  from  their  traditional  norms.  The  challenges  posed 
by  such  systems  present  equally  unfamiliar  problems  to  the  user  community,  since  the  elements  of 
the  entire  system  are  often  unknown  and  undergo  independent  (and  often  conflicting)  evolution. 
More  users  are  also  becoming  “user  programmers”  in  that  they  perform  the  final  adaptations 
needed  to  make  the  software  system  usable  for  their  current  purpose  [Forrester  2006]. 

Both  users  and  developers  are  struggling  with  unfamiliar  problems  for  which  solutions  are  not  yet 
codified  or,  in  some  cases,  are  not  even  conceived.  A  very  different  set  of  techniques  is  needed  for 
both  systems  and  software  engineering;  even  more,  a  very  different  set  of  perspectives  and  expec¬ 
tations  from  the  user  community  must  become  institutionalized. 

Consequently,  the  Carnegie  Mellon  Software  Engineering  Institute  (SEI)  is  engaged  in  an  initia¬ 
tive  whose  focus  is  systems  of  systems.  The  ISIS  (Integration  of  Software-Intensive  Systems) 
Initiative  was  chartered  to  address  the  interoperability  needs  of  current  and  future  government  and 
industry  organizations  as  they  face  unprecedented  issues  in  migrating  to  network-centric  opera¬ 
tions  and  systems  of  systems. 

A  major  element  in  the  ISIS  work  has  been  the  ongoing  development  of  a  set  of  practice-based 
technologies,  unified  by  a  common  set  of  core  concepts,  which  we  term  the  SoS  NavigatorSM  ap¬ 
proach.  The  initial  ideas  about  this  approach,  published  in  2006,  started  to  frame  the  problem  and 
highlighted  some  exemplar  techniques  and  a  nominal  process  for  approaching  appropriate  solu¬ 
tions.  This  technical  note  builds  on,  refines,  and  in  some  cases  moves  beyond  the  ideas  in  the 
original  SoS  Navigator,  based  on  what  we  have  learned  through  research  and  customer  engage¬ 
ments. 


Carnegie  Mellon  is  registered  in  the  U.S.  Patent  and  Trademark  Office  by  Carnegie  Mellon  University. 
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The  SoS  Navigator  technologies  as  of  this  writing  include  analysis  methods,  modeling  tools,  and 
processes.  The  fundamental  concepts  of  SoS  Navigator  2.0  target  difficult-to-perceive  aspects  of 
managing,  engineering,  and  operating  in  a  systems-of-systems  context  that  is  primarily  character¬ 
ized  by  a  need  for  distributed  collaboration  in  an  environment  of  highly  variable  demand.  Al¬ 
though  there  are  certainly  less  complex  contexts  in  which  systems  of  systems  are  developed,  op¬ 
erated,  and  evolved,  we  believe  that  finding  and  testing  techniques  and  processes  that  will  work  in 
this  complex  situation  will  ultimately  provide  useful  tools  and  techniques  for  addressing  simpler 
situations  as  well. 

As  organizations  move  toward  greater  development,  evolution,  and  use  of  such  systems,  the  SoS 
Navigator  approach  can  provide  leaders  of  those  organizations  with  insight  into  the  balance 
needed  among  the  many  participants  and  tensions  in  a  complex  system-of-systems  undertaking: 
system  creators,  providers,  vendors,  customers,  and  users;  and,  most  importantly,  the  context  in 
which  complex  systems  are  expected  to  perform. 1  The  concept  of  system  provider  accounts  for 
acquisition  agents  and  system  integrators.  In  some  situations,  they  may  also  be  considered  crea¬ 
tors. 

We  chose  the  term  navigator  intentionally.  In  the  traditional  sense  of  the  word,  a  navigator  is  the 
individual  whose  task  is  to  plan,  record,  and  direct  the  movement  of  a  ship  or  airplane  from  one 
place  to  another.  Different  navigational  techniques  have  evolved  in  different  cultures,  but  all  of 
those  techniques  involve  locating  one’s  position  compared  to  known  locations  or  patterns.  It  is 
this  notion  of  finding  one’s  position  in  an  unfamiliar  space  that  suggested  the  term  navigator  for 
our  work:  all  of  the  modeling  and  analysis  tools  and  methods  we  use  have  the  common  aim  of 
bringing  awareness  to  individuals  and  organizations  about  their  “location”  or  “bearing,”  in  the 
virtual  sense,  as  they  move  into  the  unfamiliar  and  complex  world  of  systems  of  systems. 

Just  as  a  ship’s  navigator  requires  a  large  array  of  tools  (a  traditional  set  of  navigator’s  equipment, 
according  to  Wikipedia,  could  include  dozens  of  items  [Wikimedia  2008]),  the  SoS  Navigator 
approach  relies  on  a  rich  set  of  diverse  technologies  rooted  in  a  set  of  related  concepts,  each  of 
which  has  some  specific  focus  on  a  particular  issue  or  challenge  brought  about  by  a  systems-of- 
systems  perspective. 

In  Section  2  of  this  technical  note,  we  describe  the  SoS  Navigator  approach  in  terms  of  its  evolv¬ 
ing  fundamental  concepts.  Section  2  is  aimed  at  readers  interested  in  the  “why”  of  SoS  Navigator. 
In  Section  3,  we  describe  the  essential  techniques  and  processes  of  this  approach  that  have  proved 
useful  to  date;  it  is  meant  for  readers  more  interested  in  “what  is”  SoS  Navigator.  In  Section  4,  we 
briefly  describe  some  of  the  uses  of  the  SoS  Navigator  approach  in  real-world  contexts.  It  ad¬ 
dresses  readers  interested  in  “where  has  it  been  used.”  In  Section  5,  we  briefly  discuss  our  plans 
for  future  work,  addressing  “where  are  we  going  from  here.”  It  is  important  to  note  that  subse¬ 
quent  technical  reports  and  notes  will  provide  additional  detail  on  all  of  these  topics,  which  are 
presented  here  in  only  a  general  introductory  manner. 


Where  no  ambiguity  is  likely,  we  shall  from  this  point  shorten  “complex  systems  of  systems”  to  the  simpler  term 
complex  systems  or  just  systems  and  use  the  longer  phrase  only  when  necessary. 
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2  Fundamental  Concepts  that  Support  SoS  Navigator 


The  SoS  Navigator  approach  is  intended  to  provide  insight  into  the  balance  needed  among  the 
many  participants  and  tensions  in  a  complex  system-of-systems  undertaking.  We  define  a  com¬ 
plex  system  of  systems  as  a  collaboration  among  autonomous  systems  that  occurs  in  relation  to 
some  business  purpose  or  mission  objective  and  within  a  changing  and  unpredictable  context. 
Some  of  these  systems  are  technical  (e.g.,  software  and  hardware),  others  are  organizational  (i.e., 
involving  humans).  Within  SoS  Navigator  we  are  therefore  dealing  with  socio-technical  systems 
as  a  whole. 

We  are  not  the  first  researchers  to  address  socio-technical  issues  of  complex  systems.  The  study 
of  systems  and  the  way  humans  and  groups  of  humans  interact  with  and  are  a  part  of  them  goes 
back  decades,  at  least  as  far  as  the  work  of  the  Tavistock  Institute  of  Human  Relations  [Trist  and 
Murray  1990,  1993]  and  of  the  management  cybernetics  movement  of  the  1950s  [Beer  1959].  The 
growth  of  study  in  these  topics  has  led  to  many  different  branches  and  a  rich  source  of  ideas,  in¬ 
cluding  systems  theory,  systems  thinking,  cybernetics,  complex  adaptive  systems,  non-linear  sys¬ 
tems,  and  systemics.  Although  we  have  been  influenced  by  several  of  these  heritages,  our  work 
draws  particularly  on  ideas  from  Maturana  and  Varela  [Maturana  and  Varela  1980]  related  to  the 
nature  of  autonomous  behavior,  the  work  of  Kolb  [Kolb  1984]  in  terms  of  experiential  learning, 
and  the  work  of  Rosen  [Rosen  1991]  in  tenns  of  the  relational  approach  to  understanding  anticipa- 
tive  systems.  Our  perspective  is  concerned  with  the  nature  of  dynamic  living  systems,  rather  than 
with  mechanistic  or  purely  structure-determined  ones.2 

By  recognizing  that  systems  of  systems  are  socio-technical  collaborations  [Hirschhorn  1984],  we 
focus  on  what  is  normally  thought  of  as  the  customer  of  the  system  of  systems  rather  than  on  the 
supplier  of  an  individual  constituent  system.  The  customer  of  the  systems  of  systems  is,  in  fact,  an 
enterprise  that  uses  systems  to  provide  services  to  its  own  customers — the  service  users.  Table  1 
shows  high-level  definitions  for  the  main  roles  we  discuss  for  a  complex  system-of-systems  col¬ 
laboration. 

Table  1:  Definition  of  Key  Roles 


System  Supplier 

The  entity  that  creates  and  offers  some  system  element  for  use  by  others 

Customer  Enterprise 

The  enterprise  that  uses  systems  to  provide  services  to  service  users 

Service  User 

Those  who  express  demand  for  and  use  the  services  of  the  customer  enterprise 

The  example  of  an  electronic  medical  record  service  (EMRS)  in  one  hospital,  viewed  as  a  single 
customer  enterprise,  illustrates  this  view  of  complex  systems  of  systems.  For  this  EMRS,  the 
complex  socio-technical  system  of  systems  encompasses  the  supplier  of  the  EMR  software,  the 
deployment  organization  within  the  hospital  that  will  use  the  EMR  software  to  provide  a  service 
(i.e.,  customized  access  to  medical  records),  and  the  IT  group  in  the  hospital  that  will  host  and 
sustain  it.  The  clinicians  who  will  use  it  and  probably  others  (including  patients)  become  the  ser- 


A  future  technical  note  will  explore  the  roots  of  our  ideas  and  how  they  have  led  to  our  current  thinking.  For  this 
overview  report,  we  allude  to  these  few  sources  to  help  orient  readers  who  are  interested  in  systems  science 
connections. 
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vice  users.  Note  that  there  can  be  many  suppliers,  both  outside  and  inside  the  hospital.  Table  2 
places  the  roles  in  the  EMRS  example  in  the  context  of  our  high-level  definitions.  If  the  EMRS 
were  to  be  shared  in  a  Regional  Healthcare  Information  Organization  (RHIO)  with  several  par¬ 
ticipating  hospitals,  clinics,  and  pharmacies,  the  number  of  suppliers  and  customers — and  the 
complexity  of  understanding  the  system  of  systems — would  grow. 

Table  2:  Key  Roles  in  a  Simple  Context 


Role 

High-Level  Definition 

Definition  Applied  to  EMR  Example 

System 

Supplier 

The  entity  that  creates  and  offers  some 
system  element  for  use  by  others 

The  organization(s)  that  develop(s)  the  EMR 
software 

Customer 

Enterprise 

The  enterprise  that  uses  systems  to 
provide  services  to  service  users 

The  EMRS  deployment  organization  in  the  hos¬ 
pital;  the  IT  organization  in  the  hospital 

Service  User 

Those  who  express  demand  for  and  use 
the  services  of  the  customer  enterprise 

The  clinicians  (and  potentially  the  patients) 

In  a  DoD  context,  the  system  supplier  is  likely  to  be  a  contractor,  while  the  customer  enterprise  is 
a  logistics  organization  within  one  of  the  military  services,  and  the  service  users  would  be  the 
military  units  operating  in  the  field  who  are  using  the  IT  and  other  services  provided  by  the  logis¬ 
tics  organization. 

When  we  shift  our  focus  on  complex  systems  of  systems  from  system  supplier  to  customer  enter¬ 
prise,  we  must  also  change  many  of  our  traditional  ways  of  thinking  about  engineering  and  man¬ 
agement  [Fisher  2007].  Making  this  shift  introduces  a  number  of  related  challenges,  such  as 

•  unknown  internal  and  external  suppliers  of  component  systems  within  systems  of  systems 

•  lack  of  a  global  view  of  the  systems  of  systems  by  any  one  of  these  suppliers 

•  system-of-systems  composite  capabilities  unable  to  keep  up  with  service  users’  needs 

•  unanticipated  behaviors  emerging  between  component  systems 

•  latent  incompatibilities  between  component  systems 

•  synchronization  challenges  across  the  systems  of  systems 

•  different  meaning  attached  to  common  terminology  across  the  systems  of  systems 

•  fusing  of  data  and  information  across  the  systems  of  systems 

Underlying  these  kinds  of  system-of-systems  challenges  are  (1)  difficulties  in  seeing  the  whole 
system  (e.g.,  lack  of  a  global  view)  and  (2)  effectively  communicating  relevant  information  (e.g., 
different  understanding  of  terminology). 

The  SoS  Navigator  approach  offers  tools  to  address  both  kinds  of  challenge  through  improving 
awareness  of  the  many  tensions  that  have  to  be  balanced  in  a  systems-of-systems  situation  and 
understanding  the  kinds  of  communication  that  are  required  across  diverse  participants  in  systems 
of  systems.  The  focus  of  this  approach  is  the  relationship  between  suppliers  and  customers  in  the 
context  of  continually  changing  requirements  (demand)  from  the  users  of  the  services  provided  by 
the  customer  enterprise.  The  SoS  Navigator  approach  explores  that  relationship  through  several 
interrelated  concepts,  which  are  addressed  in  the  sections  that  follow: 

1 .  the  customer  enterprise  and  the  purchaser-provider  boundary 

2.  supply,  demand,  and  organizational  context 

3.  the  gap  between  supply  and  demand 
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4.  the  importance  of  context-of-use 

5.  the  double  challenge  of  governance  and  demand 

6.  the  implications  of  decentralized  governance 

7.  the  requirement  for  agility 

2.1  THE  FOUNDATION:  THE  SOS  ENTERPRISE  AND  THE  PURCHASER-PROVIDER 
BOUNDARY 

A  concept  that  figures  prominently  in  almost  all  discussions  of  systems  is  that  of  an  enterprise. 
This  term  has  many  definitions;  the  following  are  representative: 

An  enterprise  (or  "company")  is  comprised  of  all  the  establishments  that  operate  under  the 
ownership  or  control  of  a  single  organization.  An  enterprise  may  be  a  business,  service,  or 
membership  organization;  consist  of  one  or  several  establishments;  and  operate  at  one  or 
several  locations. .  .  [USCB  2002]. 

[An  enterprise]  is  a  collection  of  organizations  and  people  formed  to  create  and  deliver 
products  to  customers  [Oracle  2007]. 

[An  enterprise  is]  a  system  of  business  endeavor  within  a  particular  business  environment 
.  .  .[it  includes]  an  enterprise  architecture  (EA),  which  is  a  design  for  the  arrangement  and 
interoperation  of  business  components  ([e.g.],  policies,  operations,  infrastructure,  informa¬ 
tion)  that  together  make  up  the  enterprise's  means  of  operation  [BSI  2007]. 

In  general,  the  concept  refers  to  a  collection  of  organizational  entities,  persons,  processes,  and 
systems  that  together  are  engaged  in  some  common  purpose  under  a  single  source  of  control  (by 
control  we  primarily  mean  decision-making  authority).  But  the  overall  concept  can  be  recursive, 
which  sometimes  makes  its  use  ambiguous.  For  instance,  the  DoD  will  often  refer  to  itself  as  an 
enterprise.  But  within  the  DoD,  the  Air  Force  also  refers  to  itself  as  an  enterprise,  and  within  the 
Air  Force,  many  of  its  constituent  commands  also  refer  to  themselves  as  enterprises.  In  each  case, 
what  is  being  referred  to  is  actually  a  locus  of  control.  This  distinction  is  important,  because  when 
we  place  a  boundary  around  an  enterprise,  we  do  so  by  reference  to  what  it  controls  not  to  what  it 
“owns.” 

Consequently,  systems  suppliers — commercial  software  contractors,  for  instance — that  are  seen  as 

being  outside  the  customer  enterprise  in  ownership  terms  fall  within  the  boundaries  of  a  customer 

3 

enterprise  when  they  come  under  its  control  as  sub-contractors. 

An  important  boundary  to  establish  between  a  customer  enterprise  and  the  users  of  its  services  is 
between  the  user  as  purchaser  of  both  products  and  associated  services  and  the  enterprise  as  the 
provider  across  which  services  (that  include  the  products)  are  provided.4  The  providers  satisfy  one 
or  (typically)  more  demands  from  the  purchaser  side  of  the  boundary.  Figure  1  illustrates  this  tra¬ 
ditional  way  of  thinking  about  the  purchaser-provider  boundary,  with  the  purchaser  being  the  cus¬ 
tomer  enterprise,  and  the  provider  being  the  systems  supplier. 


In  order  to  distinguish  it  from  the  definition  of  boundary  in  terms  of  ownership,  it  is  useful  to  refer  to  a  boundary 
established  by  control  as  a  perimeter. 

We  use  purchaser-provider  rather  than  customer-supplier  boundary.  A  customer-supplier  boundary  carries  the 
connotation  of  the  situation  where  a  service  is  being  supplied  to  a  customer  from  a  supplier  outside  the  enter¬ 
prise.  In  complex  systems  of  systems,  customers  are  supplied  with  services  from  suppliers  both  inside  and  out¬ 
side  of  the  enterprise. 
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Traditional  systems 
perspective 


Systems  Supplier 


C Purchaser-Provider 
boundary 


system 
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User  of  Service 
supplied  by  the 
Customer  Enterprise 


Figure  1:  Traditional  Systems  and  Customer  Enterprise  Views  of  the  Purchaser-Provider  Boundary 

The  view  in  Figure  1  contrasts  with  the  view  of  the  customer  enterprise  in  Figure  2  in  which  sys¬ 
tem  suppliers  come  under  the  control  of  what  we  now  call  the  SoS  Enterprise,  which  does  include 
the  customer  enterprise  (typically  as  subcontractors).  The  purchaser-provider  boundary  moves 
between  the  SoS  enterprise  and  the  users  of  their  services.  This  implies  that  the  new  boundary 
involves  both  products  and  services.  This  shift  occurs  because  the  system  suppliers  are  now  par¬ 
ticipating  with  elements  of  their  customers  to  provide  integrated  solutions  to  those  service  users, 
who  may  or  may  not  “see”  the  system  supplier  as  a  separate  entity.  The  former  customer-only 
enterprise  now  needs  to  be  treated  explicitly  as  a  complex  socio-technical  system  of  systems. 


User  of  Service 
supplied  by  the 
SoS  Enterprise 


Figure  2:  Purchaser-Provider  Boundary  in  Socio-Technical  View  of  Systems  of  Systems 

Even  though  it  is  crucial  to  determining  the  context  in  which  demands  arise,  the  purchaser- 
provider  boundary  of  the  SoS  enterprise  is  often  not  clear  to  suppliers.  Consider  a  hospital  that  has 
outsourced  the  maintenance  of  healthcare  records.  The  various  clinicians  are  the  primary  users  of 
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the  services  provided  by  a  hospital  enterprise  (for  the  benefit  of  the  patient).5  The  provider  of 
healthcare  records  is  a  supplier  to  the  hospital  enterprise,  and  the  record  supplier’s  customers  are 
medical  staff  working  directly  under  the  authority  of  the  hospital  enterprise.  Partner  pharmacies 
that  accept  electronic  prescriptions  from  the  hospital  cede  some  control  to  the  provider  of  health¬ 
care  records  (they  have  provided  the  healthcare-record  provider  with  access  to  certain  of  their  in¬ 
ternal  records  that  are  normally  considered  to  be  within  the  purview  of  the  pharmacy)  and  thus  are 
considered  within  the  hospital  enterprise.  Note  that  online  pharmacies  that  have  no  connections  to 
the  hospital’s  healthcare  records  are  considered  outside  the  hospital  enterprise;  indeed,  they  are 
competing  with  the  services  provided  by  the  hospital  enterprise. 

The  SoS  Navigator  approach  helps  leaders  of  an  organization  understand  the  SoS  enterprise  in 
which  they  participate,  where  their  defining  purchaser-provider  boundaries  are,  and  how  to  in¬ 
clude  the  socio-technical  elements  in  the  way  they  define  themselves  as  a  system  of  systems.  It 
also  clarifies  the  role  of  the  acquisition  function  in  managing  the  supply  side  of  the  SoS  Enterprise 
[Smith  2006], 

A  key  implication  of  the  shift  in  purchaser-provider  boundary  described  in  Figure  2  is  that  the 
relationships  among  suppliers,  customers,  and  service  users  not  only  are  different  from  those  im¬ 
plied  in  Figure  1  but  also  shift  as  the  demands  of  service  users  change  and  the  capacity  of  the  SoS 
Enterprise  to  shift  its  business  models  changes.  A  future  technical  note  will  deal  explicitly  with 
this  implication  through  elaboration  of  the  value  stairs  concept  [Boxer  2007a]. 

2.2  SUPPLY,  DEMAND,  AND  ORGANIZATIONAL  CONTEXT 

In  our  usage,  supply  refers  to  any  of  the  enterprise  participants  that  provide  a  system  or  a  part  of  a 
system  to  system  users  (or  integrators)  who  will  employ  it  in  the  course  of  providing  services  to 
the  service  users.  Examples  of  suppliers  are  COTS  tool  vendors  and  traditional  system  developers. 
Demand  refers  most  immediately  to  the  use  made  of  the  services  provided  by  the  SoS  enterprise 
and  the  needs  that  generate  those  uses.6  But  it  also  refers  to  the  more  general  operational  envi¬ 
ronment  (e.g.,  the  constraints  imposed  by  policy,  regulation,  etc.)  in  which  those  service  users 
function.7 

In  the  past,  demand  has  been  expressed  (from  the  system  supplier  viewpoint)  primarily  through 
the  notion  of  specified  requirements.  Using  requirements  as  the  sole  expression  of  demand  has  led 
to  difficulties  in  the  past,  but  the  practice  has  persisted  in  many  environments  as  the  primary 
communication  vehicle  across  the  traditional  style  of  purchaser-provider  boundary  (Figure  1,  page 
6). 

But,  as  both  the  systems  of  systems  and  their  demand  contexts — the  contexts  they  are  responding 
to  with  services — become  more  complicated,  we  need  to  move  toward  the  SoS  enterprise  way  of 
looking  at  the  purchaser-provider  boundary  (Figure  2,  page  6  ).  Under  these  conditions,  require- 


Direct  patient  access  and  use  of  their  patient  record  is  not  far  off,  with  the  advent  of  both  Google  and  Microsoft 
“vaults”  for  patient  records. 

In  this  document,  we  use  services  in  a  traditional  sense,  not  in  the  sense  of  services  in  a  service-oriented  archi¬ 
tecture  environment. 

An  entity  that  supplies  is  commonly  called  a  supplier.  But  the  name  for  an  entity  that  demands  offers  a  slight 
problem  in  terminology,  because  although  “demander”  is  a  valid  English  word,  its  use  is  awkward.  We  prefer  to 
substitute  “user”  as  the  entity  that  demands.  We  shall  clarify  among  these  terms  when  ambiguity  might  arise. 
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ments  cannot  adequately  represent  more  than  a  snapshot  of  a  subset  of  the  demands  that  exist  in 
the  dynamic  operational  environment  of  users  of  services  provided  by  the  SoS  enterprise.  The 
concept  of  demand  is  therefore  expanded  beyond  our  traditional  notion  of  requirements  to  include 
the 

•  context-of-use  in  which  services  provided  by  SoS  enterprises  will  be  used 

•  constraints  of  operations,  regulations,  and  policy  governing  the  use  of  those  services 

It  has  become  very  clear  over  the  past  several  decades  that  turbulence  in  these  contexts-of-use  is 
giving  rise  to  greater  and  greater  demands  by  users  on  SoS  enterprises  [Emery  1965,  Normann 
2001].  Service  users  are  demanding  specialized  solutions  in  ever  shorter  time  frames;  they  are 
also  insisting  that  these  solutions  be  continuously  adapted  to  their  changing  and  evolving  con¬ 
texts-of-use.  The  rapid  evolution  in  cell  phone  technology  over  the  past  few  years  from  wireless 
telephones  to  cameras  to  music  players  to  internet  devices  to  integrated  sets  of  all  of  the  above  is 
characteristic  of  such  a  rapid  evolution  of  services  in  response  to  new  and  changing  forms  of  de¬ 
mand.  A  fundamental  assertion  of  the  SoS  Navigator  approach  is  that  the  contexts-of-use  of  the 
services  provided  by  the  SoS  enterprise  are  all-important  to  understanding  the  demands  to  which 
the  SoS  enterprise  must  respond.  This  approach  advances  the  idea  that  understanding  the  con¬ 
texts-of-use  on  the  demand  side  enables  more  effective  response  to  the  demand  environment 
[Boxer  2006a]. 

Nuances  of  “Demand” 

As  formulated  in  the  section  above,  we  define  demand  as  the  particular  ways  in  which  service 
users  define  their  needs,  a  concept  more  nuanced  than  the  simple  notion  of  requirements.  The 
EMR  service,  for  example,  shows  some  of  the  ways  in  which  demand  can  go  beyond  typical  no¬ 
tions  of  requirement.  The  demand  environment  for  EMR  services  includes  the  highly  variable 
hospital  policy  environments  where  those  services  are  deployed,  which  may  necessitate  some  fea¬ 
tures  of  the  EMR  services  to  be  “turned  off’  to  meet  local  policy  constraints. 

Demand  can  be  seen  as  symmetric  or  asymmetric.  Symmetric  demand  describes  an  expectation  by 
an  SoS  enterprise  that  a  proportionate  and  stable  relationship  exists  between  the  user’s  needs  and 
the  enterprise’s  understanding  of  those  needs  as  expressed  in  the  services  it  is  prepared  to  provide. 
In  other  words,  the  enterprise  offers  a  product  or  solution  that  is  in  its  interests  to  provide  and 
which  it  expects  will  fit  stated  (or  unstated)  demands  of  users  (i.e.,  product  or  solution  drives  the 
use). 

Asymmetric  demand  embodies  the  idea  that  an  SoS  enterprise  must  shape  its  services  dynamically 
to  meet  changing  demands  in  ways  that  may  or  may  not  fit  its  interests  as  it  currently  defines 
them.  In  responding  to  asymmetric  demand,  an  SoS  enterprise  is  accepting  that  its  interests  are 
served  when  the  needs  of  the  service  user  drive  its  understanding  and  interest.  The  service  user’s 
demand  is  specific  to  its  experience  of  a  particular  context-of-use  and  that  demand  can  rapidly 
evolve  as  the  service  user’s  context  and  understanding  of  its  need  changes.  To  meet  such  a  rapidly 
evolving  demand,  a  systems  supplier  within  the  SoS  enterprise  must  also  become  flexible  and 
adaptable.  Furthermore,  the  service  user’s  expectations  for  systems  supplier  flexibility  can  shape 
the  demands  they  make  on  the  SoS  enterprise.  It  is  important  to  understand  that  when  a  supplier 


The  ultimate  end  user  may  be  several  layers  removed  from  a  given  supplier,  producing  interesting  challenges 
for  understanding  the  customer-of-the-customer’s  (etc.)  demand.  This  circumstance  requires  careful  placement 
and  recognition  of  observer  perspective:  multiple  perspectives  at  different  layers  may  be  very  appropriate. 
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within  the  SoS  enterprise  is  able  to  dynamically  support  the  satisfaction  of  one  or  more  asymmet¬ 
ric  demands  being  responded  to  by  the  SoS  enterprise,  we  are  not  asserting  that  this  converts  the 
demand  to  being  symmetric.  Instead,  satisfying  an  asymmetric  demand  is  a  continual  process  of 
defining  the  interests  of  the  SoS  enterprise  in  terms  of  its  service  users’  interests  and  will  be  asso¬ 
ciated  with  continually  changing  responses  to  the  users’  dynamically  evolving  demands.  Beyond  a 
characterization  of  demand  as  symmetric  or  asymmetric,  there  are  other  nuances  that  affect  com¬ 
plex  systems.  For  instance,  demand,  whether  symmetric  or  asymmetric,  can  also  be  predictable  or 
unpredictable;  its  rate  of  change  can  be  fast  or  slow.  However,  it  is  with  the  distinction  between 
symmetric  and  asymmetric  demand  that  we  are  most  concerned,  because  in  the  context  of  com¬ 
plex  systems,  demand  is  largely  asymmetric.  Any  asymmetric  demand  requires  a  dynamic  respon¬ 
siveness  on  the  part  of  the  SoS  enterprise. 

We  seek,  therefore,  using  the  tools  and  techniques  within  SoS  Navigator,  to  make  clear  how 
asymmetric  demand  will  be  present  in  different  and  dynamic  ways,  how  demands  may  interact  in 
a  given  context-of-use,  and  how  SoS  enterprises  can  find  dynamic  ways  to  meet  those  demands. 

2.3  THE  GAP  BETWEEN  SUPPLY  AND  DEMAND 

Based  on  the  expanded  notion  of  demand  espoused  above,  a  gap  between  supply  and  demand 
emerges  from  the  lack  of  direct  connection  between  the  service  users  and  the  systems  that  are 
provided  by  suppliers  to  support  the  SoS  enterprises  that  are  actually  delivering  services  to  those 
users.  Complicating  this  separation  and  making  it  progressively  more  difficult  to  fully  understand 
complex  systems  is  that  the  service  users’  needs  and  the  socio-technical  contexts  in  which  those 
needs  arise  are  themselves  constantly  evolving,  usually  independently,  with  their  future  states 
largely  unknown. 

As  a  result,  if  service  users’  needs  are  sufficiently  urgent  but  the  systems  and  tools  available  to  the 
SoS  enterprise  are  inadequate  to  satisfy  the  needs  of  the  task  at  hand,  the  SoS  enterprise  must  find 
alternative  ways  to  make  do,  by  developing  workarounds,  modifying  and  adapting  existing  sys¬ 
tems  and  tools,  or  finding  other  sources  beyond  the  system  suppliers  they  have  used  in  the  past. 
The  modifications  and  adaptations  that  result  from  this  scenario  tend  to  be  ad  hoc.  Thus,  a  doctor 
without  emergency  backup  may  make  use  of  kitchen  utensils  and  adapt  the  kitchen  table  to  ap¬ 
proximate  sterile  working  conditions  in  order  to  meet  the  needs  of  patients  presenting  with  medi¬ 
cal  symptoms.  For  an  SoS  enterprise  where  there  is  a  considerable  gap  between  supply  and  de¬ 
mand,  such  workarounds  tend  to  become  very  expensive;  the  resultant  drain  on  resources  will 
ultimately  constrain  the  ability  of  that  enterprise  to  continually  respond  and  adapt  to  new  forms  of 
demand  [Boxer  2007a]. 

The  SoS  Navigator  approach  provides  analytic  tools  that  graphically  depict  this  gap  between  sup¬ 
ply  and  demand.  Through  use  of  SoS  Navigator  tools  and  techniques,  we  seek  to  define  the  degree 
to  which  the  various  participants  may  need  to  change  behaviors  in  order  to  bridge  that  gap. 

2.4  THE  IMPORTANCE  OF  CONTEXT-OF-USE 

In  a  specific  context-of-use,  a  service  user  performs  a  task  supported  by  the  services  of  an  SoS 
enterprise.  These  services  themselves  require  a  combination  of  socio-technical  system  elements 
that  need  to  interoperate.  That  combination  is  often  different  than  the  one  needed  by  other  service 
users  performing  different  tasks  in  different  contexts-of-use.  In  effect,  the  SoS  enterprise  must  be 
able  to  support  dynamically  changing  use  configurations  of  the  systems  that  must  come  into  play 
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for  dynamically  changing  contexts-of-use.  Similar  to  product  configurations,  a  use  configuration 
is  a  particular  combination  of  tasks  and  constraints  (as  opposed  to  product  elements)  that  support 
accomplishing  a  particular  goal.  Some  of  these  use  configurations  can  be  known  in  advance;  but 
one  of  the  attributes  of  asymmetric  forms  of  demand  is  that  many  of  them  can  only  be  fully  un¬ 
derstood  at  precisely  the  time  that  the  service  user  is  faced  with  changing  operational  needs. 

This  concept  can  be  illustrated  by  reference  to  the  design  of  a  certain  class  of  agile  fighter  aircraft. 
These  aircraft  are  designed  to  be  unstable  in  flight;  a  computer  must  calculate  in  real  time  how  to 
choose  the  correct  physical  configuration  of  relationships  between  its  control  surfaces,  thrust,  and 
the  pilot’s  actions.  The  agility  of  the  aircraft  comes  from  the  computer’s  ability  to  dynamically  re¬ 
organize  these  configurations  of  use  in  real  time.  A  different  example  can  be  seen  in  the  way  that 
an  unmanned  aerial  vehicle  (UAV)  can  reorganize  its  relationships  to  other  components  of  a 
C4ISTAR9  system  in  a  way  that  is  dynamically  responsive  to  the  needs  of  a  battle  commander. 

The  variety  of  demand  situations  that  an  SoS  enterprise  responds  to  often  depends  on  how  well  it 
understands  the  variety  of  use  configurations  of  its  systems  (1)  that  are  possible  and  (2)  that  it 
chooses  to  support.  A  manufacturer  of  laptop  computers,  for  example,  could  choose  not  to  ac¬ 
tively  support  the  entire  range  of  variation  requested  by  the  healthcare  market.  Demands  may  still 
arise  for  use  configurations  it  does  not  support.  But  the  manufacturer  would  not  be  the  one  to  re¬ 
spond  to  those  demands  and  would  refer  those  clients  either  implicitly  or  explicitly  to  another 
source.  This  decision  might  well  be  made  because  the  leaders  of  the  laptop  manufacturer  do  not 
want  to  invest  in  the  learning  needed  to  understand  certain  aspects  of  the  healthcare  market.  This 
is  a  symmetric  relationship  between  the  laptop  manufacturer  and  the  demand  from  the  healthcare 
market  segment. 

SoS  Navigator  analytic  tools  are  aimed  at  engineering  asymmetric  relationships  to  demand.  They 
make  transparent  (1)  the  variety  of  forms  of  demand  that  the  SoS  enterprise  might  be  expected  to 
respond  to  and  (2)  the  corresponding  variety  in  the  use  configurations  that  systems  supplied  by  the 
SoS  enterprise  must  be  able  to  support.  With  SoS  Navigator  tools,  the  SoS  enterprise  can  make 
decisions  about  what  variety  of  demand  situations  it  can  and  will  participate  in. 

2.5  THE  DOUBLE  CHALLENGE  OF  GOVERNANCE  AND  DEMAND 

In  a  complex  system,  governance  is  critical.  For  our  purposes,  governance  is  the  way  power  is 
distributed,  whether  among  suppliers  or  users,  in  a  given  enterprise  in  response  to  demand  from 
outside  the  enterprise.  We  can  place  governance,  in  its  common  senses  of  control  and  authority,  in 
relation  to  three  other  concepts:  (1)  the  aggregate  collective  resources  of  the  SoS  enterprise;  (2) 
the  demand  from  service  users  within  their  context-of-use;  and  (3)  the  ability  of  the  supplying  SoS 
enterprise  to  synthesize  multiple  solutions  with  multiple  use  configurations.  The  last  concept  re¬ 
fers  not  merely  to  traditional  engineering  skill  but  also  to  the  many  ways  an  enterprise  can  orches¬ 
trate  and  synchronize  resources  to  respond  to  a  particular  context-of-use.  For  example,  the  enter¬ 
prise  can  choose  to  co-locate  staff  resources  at  an  operational  site  or  may  only  make  them 
available  at  the  corporate  headquarters. 

Governance  maintains  balance  among  those  three  concepts.  Under  centralized  governance,  a  sin¬ 
gle  source  of  authority  exercises  control  over  the 


C4ISTAR  represents  the  military  functions  defined  by  C4  (Command,  Control,  Communications,  Computers),  I 
(military  intelligence)  and  STAR  (Surveillance,  Target  Acquisition  and  Reconnaissance). 
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•  resources  of  the  enterprise  (e.g.,  staff,  IT  systems,  specialized  tools  or  labs) 

•  ways  that  system  users  within  the  enterprise  use  resources  and  synthesize  solutions  (e.g.,  via 
integrated  product  teams,  field  offices,  or  virtual  working  groups) 

•  ways  service  users  make  use  of  the  enterprise’s  services  to  meet  demand  (e.g.,  as  part  of  a 
larger  collaborative/joint  team  to  meet  a  specific  mission) 

In  centralized  governance,  differences  and  problems  between  suppliers  and  customers  can  be  re¬ 
solved — and  balance  maintained — by  the  single  source  of  authority.  Under  conditions  of  central¬ 
ized  governance,  power  is  held  at  the  top  of  an  enterprise  and  is  expressed  in  the  form  of  a  hierar¬ 
chical  decomposition  of  roles  through  which  individuals  can  be  held  accountable  for  their 
behavior. 

However,  it  is  likely  that  meeting  service  user  demands  may  involve  multiple  SoS  enterprises — in 
acquisition,  where  large  systems  are  built  by  several  corporations,  and  in  operation,  as  when  ele¬ 
ments  from  different  branches  of  the  anned  forces  engage  in  joint  operations.  In  a  multiple- 
enterprise  context  (and  even  for  large,  nominally  single  enterprises),  different  centralized  govern¬ 
ance  structures  are  almost  inevitable.  Where  such  different  governance  structures  exist,  one  sig¬ 
nificant  challenge  is  to  assert  a  single  source  of  authority  over  different,  and  sometimes  compet¬ 
ing,  constituents,  even  in  relation  to  a  single  end-user  context  [Morris  2006]. 

Under  conditions  of  asymmetric  demand,  however,  the  exercise  of  authority  must  become  dy¬ 
namic  and  decentralized ,  enabling  power  to  be  exercised  at  the  edge  of  the  SoS  enterprise10 
[Boxer  2007b].  In  Figure  2  (page  6),  roles  operating  at  the  edge  of  the  SoS  Enterprise  are  those 
working  across  the  purchaser-provider  boundary  most  directly.  This  decentralized  form  of  gov¬ 
ernance  permits  the  service  users’  demands  to  influence  the  ways  the  enterprise’s  expertise  is  ap¬ 
plied.  It  also  provides  a  means  of  dynamic  alignment  between  the  enterprise  and  service  user  that 
is  not  usually  found  in  a  centralized  governance  environment.  For  example,  if  a  field  engineering 
organization  that  works  with  diagnosing,  supporting,  and  maintaining  complex  hardware  systems 
is  required  to  have  every  proposed  fix  or  repair,  even  if  it  fits  within  current  tolerances,  approved 
by  a  central  engineering  organization,  the  centralization  of  that  approval  is  likely  to  create  lag 
times  that  translate  into  perceived  wasted  time/effort  on  the  part  of  the  user  waiting  for  the  repairs. 
If,  however,  the  central  engineering  organization  cedes  control  over  all  changes  that  do  not  violate 
function,  form,  and  fit  requirements  to  the  field  engineers,  they  have  moved  some  of  their  control 
to  the  engineers  who  interface  directly  with  the  repair  service  users,  enabling  their  fields  engineers 
“at  the  edge”  to  make  more  effective  use  of  their  time  and  to  improve  the  service  to  their  users.  It 
also  creates  a  knowledge  management  problem  as  the  engineers  must  learn  directly  from  the  di¬ 
agnostic  experience  of  one  another. 

The  response  by  the  SoS  enterprise  must  be  inherently  based  on  the  experiences  of  the  service 
users  where  the  demand  is  encountered  (e.g.,  the  first  fire  officer  who  arrives  on  scene).  This  need 
for  the  SoS  enterprise’s  response  to  be  based  on  the  experience  of  service  users  in  a  specific  con¬ 
text  may  well  require  the  enterprise  to  change  or  realign  its  resources  to  meet  the  new  demand. 

The  SoS  enterprise  is  therefore  faced  with  a  double  challenge:  needing  to  cross  the  governance 
structures  of  multiple  enterprises  while  simultaneously  responding  appropriately  to  asymmetric 

10  “At  the  edge”  is  a  common  military  way  of  referring  to  the  users  where  the  demand  (e.g.,  threat  to  the  enter¬ 
prise)  is  encountered,  often  in  battlefield  conditions.  For  non-military  situations,  such  as  healthcare,  the  edge  is 
where  clinicians  meet  the  demands  of  patients. 
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demand  (see  Figure  3  [Boxer  2006b].  The  SoS  Navigator  approach  is  concerned  with  the  response 
of  SoS  participants  to  this  double  challenge — its  nature  and  its  difficulties. 


Increasing  Asymmetry  of  Demand 


Figure  3:  The  Governance-Demand  Double  Challenge  [Boxer  2006b] 

2.6  THE  IMPLICATIONS  OF  DECENTRALIZED  GOVERNANCE 

For  one  enterprise  alone,  moving  toward  decentralized  governance  is  difficult;  for  multiple  enter¬ 
prises,  with  many  governance  structures  that  are  engaged  in  multiple  projects,  it  can  appear  in¬ 
surmountable.  Moving  from  centralized  to  decentralized  governance  is  a  fundamental  change,  and 
it  implies  that  there  now  must  be  a  dynamic  set  of  relationships  among  the  elements  of  the  SoS 
enterprise.  Those  relationships  need  to  be  kept  in  balance,  since  power — traditionally  exercised  by 
a  central  authority  at  the  top  of  the  enterprise — now  flows  out  to  the  edge,  to  those  that  respond  to 
service  users.  This  balance  must  ultimately  be  based  on  judgments  about  what  constitutes  a  sus¬ 
tainable  business  model  for  the  SoS  enterprise:  whether  it  should  put  resources  first  or  relation¬ 
ships  to  demand  first. 

Decentralized  governance  is  part  of  the  notion  of  distributed  collaboration,  which  the  SoS  Navi¬ 
gator  approach  advances  as  an  effective  means  to  meet  the  double  challenge  [Boxer  2005].  Dis¬ 
tributed  collaboration  is  a  governance  and  synthesis  style  of  complex  socio-technical  systems. 
Through  distributed  collaboration,  the  constituent  elements  of  these  systems — technical,  organiza¬ 
tional,  or  both — can  effectively  respond  to  heterogeneous  demands  from  a  set  of  (often  diverse) 
users’  (asymmetric)  demands,  even  though  they  are  independently  managed  and  evolving.  Re¬ 
sponding  to  asymmetric  demands  through  distributed  collaboration  is  a  challenge  even  for  high- 
performing,  high-capability  organizations. 

SoS  Navigator  tools  and  techniques  provide  insight  into  the  support  structures  a  client  has  for 
governance.  An  SoS  Navigator  team  can  create  a  footprint  of  current  support  with  respect  to  cen¬ 
tralized  and  decentralized  governance,  which  allows  the  organization’s  governance  structures  to 
effectively  respond  to  asymmetric  demand  environments. 

2.7  REQUIRED  AGILITY 

A  distributed  collaboration  approach  fuels  the  SoS  enterprise  with  the  agility  it  needs  to  support 
the  variety  of  use  configurations  called  for  by  a  dynamic  enviromnent  [Boxer  2006c].  This  agility 
drives  the  SoS  enterprise  to  recompose  itself  according  to  demand-in-context  instead  of  statically 
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forming  around  supplier  capabilities.  The  agile  SoS  enterprise  is  characterized  by  its  ability  to 
recognize  and  adapt  to  unpredicted  demands  [Brewer  2006,  Ashby  1963].  SoS  Navigator  tools 
allow  organizations  to  understand  the  elements  of  agility,  such  as 

•  reuse  potential 

•  cost  of  alternatives 

•  prioritization  of  value 

•  labor  versus  automation  tradeoffs 

•  interoperability  risks 

It  is  worth  noting  that  not  all  situations  require  the  level  of  agility  described  above.  It  is  equally 
important  to  understand  the  times  when  different  types  of  agility  are  required  within  an  SoS  en¬ 
terprise,  so  that  a  balance  between  agility  and  other  organizational  drivers  can  be  sustained. 

2.8  INTERRELATED  NATURE  OF  THE  FUNDAMENTAL  CONCEPTS 

The  preceding  sections  describe  the  fundamental  concepts  in  which  the  SoS  Navigator  approach  is 
grounded,  as  summarized  in  Table  3.  Although  we  have  explained  them  separately,  the  principles 
suggest  a  coherent  and  integrated  whole: 

1 .  Central  to  the  SoS  Navigator  approach  for  understanding  complex  systems  is  that  supply- 
and-demand-in-context  reveals  all.  The  relationship  of  providers  to  demand  becomes  asym¬ 
metric  when  complex  systems  of  systems  involving  multiple  organizations  exist  in  a  turbu¬ 
lent  context-of-use. 

2.  In  turn,  all  concerned — suppliers  of  solutions,  users  at  the  operational  edge,  authorities  at  the 
top,  and  the  hierarchical  governance  structures — must  jointly  exercise  forms  of  decentralized 
governance. 

3.  Hence,  in  an  asymmetric  demand  context,  a  dynamic  balance — reflected  in  dynamic,  decen¬ 
tralized  forms  of  governance — among  the  various  players  in  an  enterprise  is  vital.  This  is  the 
key  notion:  a  balancing  form  of  governance  is  needed  that  exercises  managerial  judgment 
and  coordinates,  guides,  and  most  importantly,  gives  real  authority  to  those  best  equipped  to 
judge  the  particular  nature  of  demand — the  people  at  the  edge  of  the  enterprise. 

4.  Dynamic  balance  across  the  SoS  enterprise  provides  the  agility,  flexibility,  and  adaptability 
to  dynamically  orchestrate  and  synchronize  solutions  in  response  to  service  user  demand. 

The  needed  balance  must  be  negotiated  among  the  purchasers  and  providers  in  a  particular  situa¬ 
tion  and  constantly  re-examined  to  allow  the  SoS  enterprise  to  quickly  react  to  rapidly  shifting 
contexts-of-use.  Our  use  of  the  navigation  concept  and  its  attendant  notion  of  navigating  through  a 
complex  and  stormy  sea  of  change  emerge  from  this  fundamental  assumption  that  the  needed  bal¬ 
ance  is  dynamic  and  evolving. 
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Table  3:  Fundamental  Concepts  and  SoS  Navigator  Assertions 


Concept 

Description 

SoS  Navigator  Assertion 

SoS  enterprise  and 
the  purchaser- 
provider  boundary 

The  SoS  enterprise  includes  all  the  socio- 
technical  elements  that  are  on  the  provider 
side  of  the  purchaser-provider  boundary  in 
complex  systems  of  systems  (see  Figure 

2). 

The  SoS  Navigator  approach  helps  leaders 
understand  the  SoS  enterprise  they  partici¬ 
pate  in,  where  the  purchaser-provider 
boundary  is  in  their  situation,  and  the  way  to 
focus  on  the  socio-technical  elements  that 
are  on  the  provider  side  of  that  boundary  in 
their  environment. 

Supply,  demand, 
and  organizational 
context 

Satisfying  an  asymmetric  demand  is  an 
ongoing  process  of  continually  changing 
responses  answering  dynamically  evolv¬ 
ing,  unpredictable  demands. 

SoS  Navigator  tools  can  make  clear  how 
asymmetric  demand  will  be  present  in  differ¬ 
ent  and  dynamic  ways,  how  demands  may 
interact  in  a  given  context-of-use,  and  how 

SoS  enterprises  can  find  dynamic  ways  to 
meet  those  demands. 

Gap  between 
demand  and  supply 

The  gap  between  demand  and  supply  is 
evident  in  the  disconnection  between 
systems  suppliers  and  the  users  who  daily 
make  decisions  about  how  they  will  per¬ 
form  their  jobs  on  the  demand-side. 

Through  use  of  SoS  Navigator  tools  and 
techniques,  we  seek  to  define  the  degree  to 
which  the  various  participants  may  need  to 
change  behaviors  in  order  to  bridge  that  gap. 

Importance  of 
context-of-use 

There  are  dynamically  changing  demand 
situations  that  drive  the  required  agility. 

SoS  Navigator  analytic  tools  are  aimed  at 
helping  clients  engineer  asymmetric  relation¬ 
ships  to  demand.  They  make  transparent  (1 ) 
the  variety  of  forms  of  demand  that  the  SoS 
enterprise  might  be  expected  to  respond  to 
and  (2)  the  corresponding  variety  in  the  use 
configurations  that  systems  supplied  by  the 

SoS  enterprise  must  be  able  to  support. 

Double  challenge 
of  governance  and 
demand 

It  is  necessary  to  cross  the  boundaries  of 
the  governance  structures  of  multiple 
enterprises  to  respond  appropriately  to 
asymmetric  demand. 

The  SoS  Navigator  approach  is  concerned 
with  the  response  to  this  double  challenge — 
its  nature  and  its  difficulties. 

Implications  of 
decentralized  gov¬ 
ernance 

There  must  be  some  balancing  force  in 
place  that  maintains  a  dynamic  form  of 
governance  throughout  the  SoS  enter¬ 
prise. 

SoS  Navigator  tools  and  techniques  provide 
insight  about  the  support  structures  a  client 
has  for  centralized  and  decentralized  gov¬ 
ernance. 

Required  agility 

There  is  flexibility  and  adaptability  needed 
to  dynamically  orchestrate  and  synchro¬ 
nize  solutions  in  response  to  edge-driven 
demands. 

SoS  Navigator  tools  allow  organizations  to 
understand  the  elements  of  agility,  such  as 
reuse  potential,  cost  of  alternatives,  prioriti¬ 
zation  of  value,  labor  versus  automation 
tradeoffs,  and  interoperability  risks. 

2.9  SOME  IMPLICATIONS  OF  THE  FUNDAMENTAL  CONCEPTS 

The  concepts  fundamental  to  SoS  Navigator  have  several  implications  in  the  areas  of  process, 
economics,  interoperability,  engineering,  and  collaboration. 

2.9.1  Process  Implications 

The  major  implication  of  decentralized  governance  is  that  the  individual  at  the  edge  of  the  SoS 
provider’s  enterprise,  the  one  most  directly  facing  the  service  users’  demands,  must  be  empow¬ 
ered  with  required  authority  and  be  provided  with  the  means  to  rapidly  clarify  the  appropriate 
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tools  and  systems  needed  to  meet  service  user  demands.  This  empowerment,  and,  indeed,  the  en¬ 
tire  question  of  dynamic  balance  among  all  elements  heretofore  discussed,  is  a  matter  of  process. 

With  centralized  governance,  process  considerations  are  largely  derived  from  the  decisions  al¬ 
ready  made  about  the  enterprise’s  business  model.  We  can  describe  the  relevant  processes  as  the 
performance  of  the  following  steps: 

•  decide  what  the  demand  is,  largely  in  terms  of  requirements  and  based  on  the  business  model 
of  the  enterprise 

•  develop  an  implementation  of  those  requirements,  in  the  use  of  which  the  individuals  (includ¬ 
ing  those  at  the  edge)  can  be  trained 

•  deploy  that  implemented  functionality  and  allow  demand  to  drive  change  requests,  though  it 
will  not  necessarily  drive  the  responses  to  those  requests 

However,  in  conditions  of  decentralized  governance,  a  very  different  process  must  be  used,  one 
that  accepts  that  power  must  flow  out  to  the  edge.  This  means  that  decisions  traditionally  made 
based  on  a  power  and  authority  basis  are  now  made  based  on  a  role  in  relationship  to  the  service 
user  situation  and  on  know-how  related  to  satisfying  a  particular  service  user  demand.  In  such  a 
process,  where  relationships  to  demand  are  asymmetric,  the  service  users  must  have  access  to  so¬ 
lutions  from  suppliers  within  or  beyond  the  existing  boundaries  of  the  enterprise  who  can  furnish 
them  in  an  agile  manner.  In  this  kind  of  process,  governance  includes  a  clear  understanding  of  the 
communities  involved,  transparently  sharing  responsibility  and  accountability.  The  process  must 
also  manage  dynamic  alignment  of  roles  and  governance  structures: 

•  establishing  boundaries  on  the  relationship  of  the  various  providers  to  service  users 

•  deeply  understanding  the  service  users’  context-of-use  within  the  established  boundary 

•  coordinating  and  synchronizing  enterprise  expertise  and  assets  to  meet  service  user  demands 

•  determining  the  value  proposition  to  service  user  and  provider 

The  nature  of  the  process  steps  to  achieve  this  is  likely  to  vary  sharply  between  different  situa¬ 
tions. 

2.9.2  Economic  Implications 

For  any  SoS  enterprise,  whether  the  context  is  asymmetric  or  symmetric,  there  are  certain  costs 
associated  with  setting  up  and  maintaining  its  identity:  in  the  military,  defining  its  mission;  in  in¬ 
dustry,  establishing  the  market  it  is  chartered  or  intended  to  serve;  and  so  forth.  These  are  referred 
to  as  alignment  costs  and  are  separate  from  the  transaction  costs  that  the  enterprise  then  engages 
in  (i.e.,  as  a  supplier  to  its  user  community).  Under  symmetric  conditions,  once  an  enterprise  has 
been  set  up,  the  alignment  costs  (such  as  establishing  and  evolving  employee  training  and  policy 
and  procedure)  that  the  enterprise  incurs  primarily  stem  from  maintaining  that  identity.  But  when 
demand  is  asymmetric,  the  identity  of  the  SoS  enterprise  becomes  more  fluid  (e.g.,  markets  shift, 
different  contexts  arise),  so  that  the  enterprise  incurs  continuing  alignment  costs  associated  with 
accommodating  itself  to  those  changed  forms  of  demand.  For  example,  the  ways  in  which  the  op¬ 
erational  uses  of  UAVs  are  evolving  over  time  is  changing  the  nature  of  the  services  that  the  UAV 
Service  must  provide  in  support  of  Command.  As  a  result,  the  SoS  enterprise  providing  the  UAV 
Service  has  to  redefine  itself  from  (for  example)  being  a  provider  of  an  airborne  observation  plat¬ 
form  to  being  a  distributor  of  timely  and  relevant  pictures.  This  need  to  redefine  identity  funda- 
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mentally  changes  the  business  model  being  used  by  the  SoS  enterprise  [Boxer  2008].  The  growth 
of  the  costs  associated  with  such  dynamic  realignment  can  be  very  great  when  compared  with  the 
costs  of  its  transactions.  Generally,  these  costs  are  only  included  in  the  way  the  enterprise  man¬ 
ages  its  economics  at  times  of  major  step-changes  in  its  overall  identity. 

2.9.3  Interoperability  Implications 

Regardless  of  how  the  functionality  of  systems  of  systems  may  initially  be  defined,  service  users 
will  inevitably  find  new  and  unanticipated  ways  of  expecting  the  functional  elements  to  interoper¬ 
ate.  To  accommodate  the  inevitability  of  service  users  finding  different  ways  to  combine  system 
elements,  the  enterprises  as  well  as  the  constituent  systems  must  be  sufficiently  agile  to  permit 
their  rapid  recomposition.  Thus,  system  elements  must  be  able  to  be  used  in  combinations  that 
were  not  originally  planned  for,  and  elements  need  to  be  able  to  be  interfaced  in  ways  that  the 
original  designers  never  anticipated  (including  those  not  presently  sourced  from  within  the  enter¬ 
prise).  Note  that  we  are  not  referring  here  to  creating  additional  functionality  per  se  but  rather  to 
how  various  functional  elements  can  be  composed  and  recomposed  in  relation  to  one  another. 

2.9.4  Collaboration  Implications 

In  an  asymmetric  context,  there  will  be  many  forms  of  collaboration,  each  of  which  must  be 
suited  to  and  aligned  with  particular  forms  of  demand.  These  different  instances  of  collaboration 
can  be  organized  and  engineered  to  maximize  agility  (or  optimized  to  determine  required  agility). 
SoS  Navigator  uses  multi-layer  models  to  represent  and  subsequently  reason  about  many  aspects 
of  the  SoS  enterprise  and  its  situation  (interoperability  risks,  end-to-end  demand  response,  com¬ 
ponent  granularity,  interface  requirements,  and  the  like). 

2.9.5  Engineering  Implications 

The  ways  in  which  functional  elements  can  be  composed  and  recomposed  in  relation  to  one  an¬ 
other,  like  LEGO  ”  bricks,  depend  on  the  way  the  functional  elements  are  themselves  defined.  The 
greater  the  variety  of  use  configurations  that  a  system  of  systems  must  support,  the  more  impor¬ 
tant  it  becomes  to  define  the  individual  functional  elements  (i.e.,  their  granularity)  in  ways  that 
maximize  their  use  at  the  composite  level.  The  SoS  Navigator  approach  provides  ways  of  (1)  rep¬ 
resenting  the  required  variety,  (2)  analyzing  the  composite  uses  they  give  rise  to,  and  (3)  showing 
how  the  underlying  functional  granularity  interacts  with  this  variety  of  uses. 
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3  SoS  Navigator  Approach 


The  SoS  Navigator  approach  includes  a  process  and  a  supporting  set  of  tools.  Together,  they  can 
be  used  to  analyze  a  client’s  present  circumstance  and  recommend  transformations  that  better  ac¬ 
commodate  the  needs  of  asymmetric  demand  and  decentralized  governance.  The  client  here  is 
assumed  to  be  an  SoS  enterprise,  so  that  we  can  now  refer  to  its  service  users  as  its  customers. 

The  tools  include  a  rich  set  of  modeling  techniques.  In  this  section,  we  summarize  both  the  proc¬ 
ess  and  the  supporting  tools. 

The  SoS  Navigator  process  framework  has  two  parts:  (1)  the  framing  process  and  (2)  a  leam- 
ing/transformation  cycle.  The  framing  process  focuses  on  providing  understanding,  along  multiple 
dimensions,  of  how  the  client  organization  is  an  SoS  enterprise,  potentially  in  collaboration  with 
other  SoS  enterprises1 1  [Anderson  2006].  SoS  Navigator  framing  enables  the  client  to  decide  to 
what  extent  it  needs  to  adopt  new  business  models  and  strategies  that  require  distributed  collabo¬ 
ration.  The  composition  of  the  SoS  Navigator  learning/transformation  cycle,  for  the  client,  de¬ 
pends  on  the  outcome  of  the  framing  process.  To  the  extent  that  change  is  necessary,  a  targeted 
learning  and  transformation  cycle  needs  to  be  undertaken.  If  the  decision  is  that  the  client  is  not 
engaged  in  an  asymmetric  demand  situation,  it  is  likely  that  more  traditional  change  management 
approaches  to  deal  with  the  client’s  problem  would  be  undertaken.  Some  individual  SoS  Naviga¬ 
tor  tools  might  be  used  in  this  instance,  but  not  in  the  integrated  fashion  that  would  be  applied  in 
an  asymmetric  demand  client  situation.  Table  4  summarizes  the  parts  of  the  process. 

Table  4:  Top-Level  View  of  Navigator  Process 


Framing  Process 

Learning/Transformation  Cycle 

•  Understand  the  relevant 
participants 

•  Decide  if  SoS  enterprise 
needs  to  respond  to 
asymmetric  demand  (If 
yes,  proceed  to  Learn¬ 
ing/Transformation  Cy¬ 
cle.) 

•  Transform  business 
model  to  support  dy¬ 
namically  responding  to 
asymmetric  demand 

•  Define  organizational 
and  technical 
changes  needed 

•  Support  integration 
and  institutionalization 
of  changes 

3.1  THE  FRAMING  PROCESS  AND  SUPPORTING  TECHNIQUES  AND  TOOLS 

Much  of  the  framing  process  is  diagnostic.  After  studying  the  issues  presented  by  the  client  or¬ 
ganization,  the  SEI’s  SoS  Navigator  team  selects  one  or  more  diagnostic  techniques  to  gain  a 
clearer  picture  of  the  supply  and  demand  sides  of  the  client’s  situation.  The  steps  in  the  framing 
process  and  their  associated  diagnostic  techniques  are  summarized  in  Table  5. 


11  In  Section  2,  we  focused  primarily  on  an  enterprise  as  a  whole.  Most  enterprises  are  themselves  socio-technical 
systems  of  systems,  so  that  when  applying  SoS  Navigator  processes  and  tools,  we  find  ourselves  working  with 
subsystems  of  the  entire  enterprise.  So  we  discuss  the  use  of  tools  and  methods  in  this  section  in  relation  to  a 
client  organization,  which  is  always  within  the  context  of  an  enterprise  as  a  whole  as  we  discussed  in  Section  2. 
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Table  5:  SoS  Navigator  Framing  Process  Steps  and  Supporting  Techniques 

Framing  Step 

Sample  Questions  this  Step 
Answers 

Techniques 

SoS  Navigator  Activities 

Identify  the  variety  of  stakeholders 
and  the  demands  they  currently 
put  on  the  SoS  enterprise 

Who  are  the  influences  on 
getting  the  solutions  out  to  the 
client’s  customers? 

Collaboration 

Stakeholder 

Analysis 

• 

Looks  at  four  types  of  stakeholder  and  their  relationships  to  help  the  client  understand  where 
appropriate  and  inappropriate  influences  are  affecting  its  ability  to  deliver  effective  solutions 
into  its  demand  environment. 

How  do  they  affect  each  other 
and  the  client  organization? 

Value  Network 
Analysis 

• 

Looks  at  particular  stakeholders  and  the  value  exchange  between  them  and  the  client  or¬ 
ganization  for  relevant  patterns  and  misalignments. 

Identify  the  influences  on  current 
and  future  demand  from  the 
environment  in  which  the  SoS 

What  is  the  client's  proposition 
as  to  how  it  responds  to 
demand? 

Proposition 

Analysis 

• 

Looks  at  four  types  of  possibility  for  value  propositions  (replication,  capability,  knowledge, 
and  problem)  and  provides  feedback  on  how  the  client  might  improve  its  value  proposition  to 
be  more  effective  in  responding  to  its  demand  environment. 

enterprise  operates 

What  does  the  variety  of  the 
demand  environment  look  like? 

Scenario  Analysis 

• 

From  the  external  environment  inward,  formulates  a  set  of  scenarios  that  reflect  today's  vari¬ 
ety  of  contexts  in  which  demands  are  arising,  or  the  future's,  or  both.  (These  scenarios  can 
be  used  to  model  different  types  of  demand  situation  and  to  informally  test  different  strate¬ 
gies  for  relating  to  those  demands.) 

Analyze  the  governance  and 
support  structures  involved  in  the 
SoS  enterprise  and  their 

Where  are  the  different  centers 
of  power  within  the  client 
organization  and  the  key 

Influence  Map 
Analysis 

• 

Captures  aspects  of  the  social  network  that  is  present  in  the  organizations  participating  in 
systems  of  systems.  (Can  leverage  work  done  in  the  Collaboration  Stakeholder  Analysis  or 
be  conducted  independently.) 

(mis)alignment  to  the  varieties  of 
demand  placed  on  it 
(This  is  the  conceptual  version  of 
an  analysis  that  is  investigated  in 
more  depth  during  a  learn¬ 
ing/transformation  cycle.) 


players  it  collaborates  with  in 
the  SoS  enterprise? 

In  what  ways  are  the  client’s 
accountability  and  responsibility 
structures  congruent  with  its 
intended  proposition  within  the 
demand  environment? 


Congruence 

Analysis 


Value  Stairs 
Analysis 


Looks  at  where  the  structures  of  the  organizational  architecture  support  or  contradict  the 
desired  propositions  to  be  offered  in  the  demand  environment.  (This  analysis  depends  on  the 
Proposition  Analysis  having  been  completed,  and  also  benefits  from  the  Center  Push/Edge 
Pull  Analysis  having  been  done.) 

Characterizes  the  purchaser-provider  boundary  with  relation  to  the  possible  types  of  demand 
response. 

Allows  identification  of  a  strategy  ceiling,  the  level  on  the  value  stairs  matrix  above  which  the 
enterprise  chooses  not  to  define  itself  by  reference  to  its  competitors  and  customers. 


Analyze  SoS  enterprise  resources 
(elements,  infrastructure,  assets)  in 
relation  to  the  varieties  of  demand 

Does  the  technical  asset  base 
the  client  organization  is  using 
to  respond  to  demand  have 
sufficient  flexibility? 

Asset  Analysis 

•  Examines  representative  elements  and  configurations  of  the  socio-technical  assets  that 
make  up  the  client’s  offerings  to  determine  where  there  may  be  gaps  in  the  asset  develop¬ 
ment  strategies  in  relation  to  the  demand  environment.  (Often,  modeling  techniques  are 
used  here  to  provide  a  picture  of  potential  interoperability  gaps  that  are  inherent  in  the  de¬ 
velopment  strategy.) 

Analyze  how  the  variety  of  demand 
needs  to  be  supported  by  varieties 
of  relations  among  governing 
entities,  infrastructure  capabilities, 
and  functional  elements 

In  what  ways  is  the  client 
organization's  governance 
strategy  driven  from  the  center 
or  decentralized  to  "the  edge"? 

Center  Push/ 

Edge  Pull  Analysis 
[Boxer  2008] 

•  Provides  insight  about  the  support  structures  a  client  has  for  centralized  and  decentralized 
governance. 

•  Can  be  combined  with  other  analyses  to  create  a  profile  of  current  edge/center  supports 
versus  those  needed  to  effectively  respond  to  the  demand  environment. 

(The  SoS  Navigator  Team  adapts  a  military  system  called  the  Doctrine,  Organization,  Training, 
Materiel,  Leadership,  Personnel,  Facilities  [DOTMLPF]  wheel.12) 

12  The  military  uses  this  approach  to  integrate  analysis  from  all  significant  perspectives. 
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The  choice,  sequencing,  and  timing  of  the  analyses  summarized  in  Table  5  depend  on  the  context 
as  presented  by  the  client.  The  goal  is  not  to  complete  all  the  analyses,  unless  all  are  needed. 
Rather,  the  goal  is  to  use  those  analyses  that  are  relevant  to  obtaining  a  sufficient  picture  of  the 
client  and  its  relationship  to  the  problem  situation.  Through  the  appropriate  analyses,  we  deter¬ 
mine  whether 

1 .  the  organization  is  involved  in  a  distributed  collaboration,  asymmetric  demand  situation 

2.  the  organization  needs  to  or  is  ready  to  take  steps  to  be  more  effective  in  its  situation 

Where  both  of  those  conditions  are  found  to  exist,  the  framing  process  yields  a  restatement  (a  re¬ 
framing)  of  the  problem  situation  in  terms  of  what  has  been  discovered  about  the  organization  and 
its  relationship  to  its  demand  environment.  This  refrained  problem  can  then  be  used  to  enter  into 
the  activities  of  the  leaming/transformation  cycle.  Where  both  do  not  exist,  the  engagement  would 
not  be  considered  an  SoS  Navigator  engagement  and  the  team  and  client  would  decide  on  what 
kinds  of  approaches  might  be  more  suited  to  the  client  setting. 

The  suite  of  tools  and  techniques  used  to  support  the  framing  process  is  expected  to  grow  as  the 
SEI  SoS  Navigator  team  works  in  a  greater  variety  of  client  situations.  We  will  establish  a  toolkit 
for  the  framing  process  and  transformation  cycle,  which  adequately  supports  a  wide  variety  of 
enterprise  situations.  Some  of  these  tools  will  be  more  easily  conducted  “at  home,  on  your  own” 
than  others.  As  we  identify  promising  self-administered  techniques,  we  will  document  them  in 
SEI  technical  notes. 

3.2  THE  LEARNING/TRANSFORMATION  CYCLE 

Following  the  framing  of  its  situation  in  terms  of  distributed  collaboration  and  asymmetric  de¬ 
mand,  the  client  can  decide  whether  moving  to  a  dynamic  business  model  (usually  one  that  em¬ 
bodies  decentralized  governance)  must  be  taken  up  in  the  interest  of  the  enterprise.  The  SoS 
Navigator  leaming/transformation  cycle  supports  the  client  in  understanding  and  making  the  nec¬ 
essary  changes. 

Three  broad  categories  of  tasks  guide  the  transformation.  Table  6  summarizes  the  broad  steps  in 
the  leaming/transformation  cycle  and  the  activities  that  might  take  place  within  each  one.  This 
part  of  the  process  is  primarily  a  consultative  one,  so  each  situation  will  apply  the  broad  steps  dif¬ 
ferently.  As  we  identify  patterns  in  applying  these  steps,  we  will  document  them  as  part  of  the 
planned  SoS  Navigator  Analytical  Framework. 
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Table  6:  SoS  Navigator  Learning/T ransformation  Cycle 

Transformation  Step  Sample  Questions  this  Step  Possible  Subsidiary  Activities 

Answers 


Identify  the  business  and  tech¬ 
nical  strategies  to  transform  the 
organization’s  business  model 
to  support  distributed  collabora¬ 
tion  in  asymmetric  demand 
environments,  based  on  needs 
identified  in  the  framing  process. 


Work  through  the  changes 
needed  in  organization  architec¬ 
ture  and  support  structures  to 
enable  effective  distributed  col¬ 
laboration  in  asymmetric  de¬ 
mand  environments,  via  techni¬ 
cal  and  adoption  feasibility 
pilots. 

Integrate  and  institutionalize  the 
changes  needed  to  effectively 
support  distributed  collaboration 
in  asymmetric  demand  envi¬ 
ronments  on  an  ongoing  basis. 


How  does  my  business  and 
technical  strategy  need  to 
change  to  accommodate  my 
demand  environment? 


Establish  how  the  contexts-of-use  are  or¬ 
ganized 

Establish  leading  indicators  for  direction  of 
possible  futures 

Understand  data  fusion  issues  and  related 

asset  characteristics 

Describe  cohesion  of  the  enterprise 


What  is  the  most  productive 
way  for  me  to  approach  the 
needed  organizational  and 
support  architecture  changes? 


Define  structures  of  accountability  within 
the  enterprise 

Define  required  variety  of  demand  for  suc¬ 
cess 

Align  needed  functionality  to  required  varie¬ 
ties  of  demand 


Define  and  pilot  processes  of  alignment  for 
the  enterprise 


How  do  I  ensure  that  the 
needed  changes  "stick”  within 
the  fabric  of  the  organization 
over  time  with  sufficient  flexi¬ 
bility? 


Establish  operational  profiles 

Identify  and  institutionalize  configurations 
specific  to  a  particular  context-of-use 
Incorporate  relevant  scenarios  in  strategic 
planning  processes 

Close  interoperability  gaps  among  assets 


Identify  sources  of  competitive  advantage 


The  diagnostic  and  analytic  tools  and  techniques  of  the  SoS  Navigator  approach  make  consider¬ 
able  use  of  modeling,  since  an  organization  must  have  a  clear  picture  of  the  forces  that  are  at  work 
in  complex  systems  of  systems  if  they  wish  to  participate  effectively.  The  primary  modeling  tech- 
nique  used.  Projective  Analysis  (PAN),  goes  beyond  typical  business  and  organizational  model¬ 
ing  techniques  by  addressing  both  supply-  and  demand-side  system  elements  and  structures.  It 
also  addresses  some  aspects  of  typical  system  functional  modeling,  allowing  a  single  view  of  both 
the  supply-  and  demand-side  influences  on  a  system-of-systems  situation  [Anderson  2006]. 

3.3  SUMMARY  OF  SOS  NAVIGATOR  PROCESSES  AND  TECHNIQUES 

By  using  a  process  that  contains  rich  diagnostic  and  analytic  tools,  we  seek  to  provide  novel  in¬ 
sights  into: 

•  the  realities  of  demand  for  the  actual  end  users 

•  how  suppliers  and  providers  are  organized  in  themselves,  in  relation  to  demand,  and  in  rela¬ 
tion  to  changes  in  demand 

•  the  services  required  to  respond  to  demand 

•  how  those  services  are  composed  into  capabilities 

•  how  those  capabilities  are  fielded  (deployed) 


©  Boxer  Research  Ltd  2006.  Permission  to  use  PAN  technology  is  granted  under  license  to  Carnegie  Mellon 
University. 


20  |  CMU/SEI-2008-TN-001 


•  how  the  fielded  capabilities  are  synchronized  to  produce  desired  effects 

•  the  drivers  of  effects  that  are  of  particular  significance  to  the  client’s  SoS  enterprise 

Most  of  the  tools  used  are  employed  initially  during  the  framing  process.  Some  of  those  tools 
evolve  into  further  use  in  the  leaming/transformation  cycle. 

There  must  be  strong  competitive  reasons  for  shifting  from  a  central  governance  model — 
dominated  by  high-level  governance  over  organizational  capabilities  and  resources — to  a  decen¬ 
tralized  one  that  can  accommodate  dynamic,  demand-driven  responses  to  changing  contexts.  Such 
a  shift  has  to  be  driven  directly  by  the  nature  of  demand  itself:  the  drivers  of  change  have  to  be 
the  needs  of  the  individuals  at  the  edge  of  the  enterprise.  Even  where  there  are  such  reasons,  it 
does  not  mean  that  the  whole  enterprise  has  to  change.  An  iterative  approach  should  be  taken, 
since  the  whole  change  usually  cannot  be  effected  in  one  cycle.  It  is  also  better  to  work  from  the 
strongest  demands  first  and  allow  the  learning  derived  from  responding  to  these  demands  to  shape 
subsequent  cycles. 

With  the  decentralized  governance  that  is  generally  needed  to  support  distributed  collaboration  in 
asymmetric  demand  environments,  the  process  considerations  themselves  become  central  to  sus¬ 
taining  a  dynamic  balance  among  four  elements  of  the  enterprise  (governance,  demand,  resource 
infrastructure,  and  collaborative  processes).  We  have  presented  information  on  governance  and 
demand  in  Section  2.  Resource  infrastructure  is  the  totality  of  human,  material,  and  intellectual 
capital  that  is  available  to  the  enterprise  to  synthesize  products  and  services.  Collaborative  proc¬ 
esses  are  those  processes  that  are  used  to  synthesize  services  across  governance  boundaries  to 
provide  services  needed  within  the  context-of-use.  In  Section  4,  we  summarize  three  case  studies 
to  illustrate  how  these  considerations  were  addressed  and  how  the  tools  and  techniques  were  used. 
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4  Case  Summaries 


In  this  section,  we  provide  three  brief  descriptions  of  SoS  Navigator  processes  or  techniques  in 
use.  These  are  based  on  actual  client  engagements  but  are  sanitized  and  abstracted.  As  a  preface  to 
these  brief  descriptions,  we  stress  that  the  decision  to  treat  demand  as  necessarily  asymmetric  is 
ultimately  based  on  economic  and  competitive  factors.  It  reflects  the  combined  pressures  of  sup¬ 
pliers  within  an  SoS  enterprise  needing  to  get  closer  to  the  real  demands  being  felt  at  the  edge  of 
the  enterprise  and  the  escalating  costs  of  aligning  that  enterprise  to  respond  to  those  demands. 

In  the  case  study  summaries  that  follow,  we  have  provided  more  narrative  descriptions  that  give 
an  overall  impression  of  the  kinds  of  activities  in  which  we  were  engaged.  In  each  example,  a  va¬ 
riety  of  SoS  Navigator  techniques  were  used.  We  will  return  to  these  cases  in  future  technical 
notes  and  elaborate  on  details  related  to  particular  technique  use  and  process  steps,  as  appropriate. 

4.1  PROVIDING  CARE  FOR  CHRONIC  CONDITIONS14 

A  national  funding  agency  sought  to  improve  the  quality  of  the  care  it  provided  to  about  1 .2  mil¬ 
lion  patients  through  a  large  number  of  clinics  [Boxer  2006d].  The  clinical  service  was  the  client 
SoS  enterprise,  and  its  service  users  were  the  patients.  The  service  treated  chronic,  long-term  con¬ 
ditions  and  had  been  organized  to  minimize  the  cost  of  treatments,  in  terms  of  the  products  used 
and  the  use  of  clinicians.  Previous  studies  established  the  need  to  optimize  care  through  the  life  of 
the  patient’s  condition,  not  simply  to  minimize  treatment  costs. 

The  improvement  project  was  planned  over  a  three-year  cycle.  The  first  phase  involved  a  framing 
process  to  establish  the  technical  feasibility  of  the  proposed  approach  to  changing  the  clinical  ser¬ 
vice’s  role  in  treating  patient  conditions.  After  that  phase,  pathfinder  projects  would  establish  the 
adoption  feasibility  of  the  approach.  We  worked  with  nine  clinics,  chosen  to  represent  a  signifi¬ 
cant  variety  of  approaches  to  organizing  and  delivering  the  clinical  service. 

The  SoS  Navigator  framing  process  took  about  eight  months  and  involved  three  clinics  overseen 
by  the  agency,  while  the  subsequent  learning/transfonnation  cycle  activities  spanned  a  period  of 
approximately  two  years.  During  the  framing  process,  a  number  of  aspects  of  the  service  and  its 
organization  were  analyzed  using  a  range  of  SoS  Navigator  diagnostic  and  analysis  techniques 
(see  Table  4),  including: 

•  analysis  of  effects  ladders  and  propositions 

•  stakeholder  collaboration  analysis  and  modeling  of  the  processes  of  supply-demand  alignment 

•  agility  analysis  of  the  existing  systems  infrastructure  and  definition  of  clinicians’  data  fusion 
needs 

•  analysis  of  the  governance  mechanisms  and  the  economics  of  how  services  were  organized 

As  a  result,  we  established  the  viability  of  making  changes  on  both  the  supply  and  demand  sides: 
innovations  were  needed  in  the  protocols  covering  treatment  and  referral;  there  were  fundamental 
gaps  in  the  methods  of  data  fusion  needed  to  support  and  sustain  these  changes  at  the  level  of  the 


14  Although  this  case  preceded  the  incorporation  of  ideas  from  Boxer  Research  Limited  into  SoS  Navigator,  it  is 
included  here  with  Phil  Boxer’s  permission  to  illustrate  how  these  concepts  can  be  used. 
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clinic;  and  the  agency-level  approach  to  the  procurement  of  the  service  itself  needed  an  approach 
that  focused  on  the  costs  of  treating  patients  through  the  course  of  their  condition  throughout  their 
lives,  not  just  episode  by  episode.  It  was  this  shift  to  a  through-life  focus  that  made  the  demands 
on  the  clinics  explicitly  asymmetric:  instead  of  providing  standardized  treatments,  the  clinic  had 
to  manage  individual  patients’  conditions. 

During  the  subsequent  leaming/transformation  cycle,  we  executed  adoption  feasibility  projects 
(called  pathfinder  projects)  to  address  the  services  being  provided  by  six  different  clinics  within 
their  respective  healthcare  organizations.  Those  clinics  were  chosen  for  the  diversity  of  patient 
ages  (from  20  to  90),  conditions  (from  flat  feet  to  osteoarthritis  and  diabetes),  and  clinical  organi¬ 
zation  sizes  (from  small  primary  care  clinics  through  to  major  teaching  hospital  facilities  support¬ 
ing  a  regional  patient  base).  Each  pilot  we  conducted  provided  different  ways  for  the  national 
agency  to  understand  the  alignment  between  suppliers  and  users  and  represented  different  poten¬ 
tial  business  models  that  would  address  the  issues  established  in  the  framing  process.  In  each  of 
these  pathfinder  projects,  we  used  various  SoS  Navigator  tools  and  techniques  to  establish  the 
economics  involved  in  delivering  the  service,  the  processes  of  patient  referral,  the  clinic  models, 
and  the  information  support.  Based  on  these,  we  defined  the  organizational  and  technical  changes 
needed.  Implementation  of  the  projects  commenced  as  the  need  for  each  change  emerged  in  the 
organizations,  with  particular  attention  being  paid  to  how  likely  each  change  was  to  be  institution¬ 
alized  within  the  organization  and  agency. 

The  outcome  at  the  agency  level  was  twofold: 

1.  Significant  opportunities  for  cumulative  savings  were  identified  as  the  governance  shifted  to 
a  decentralized  approach. 

2.  A  new  set  of  challenges  for  transitioning  the  learning  to  other  parts  of  the  national  organiza¬ 
tion  was  identified. 

Judged  as  a  success  by  the  management  directly  involved  with  the  services,  together  with  the  cli¬ 
nicians  and  their  professional  body,  the  overall  project  raised  new  challenges  at  the  agency  level 
for  the  approach  to  institutionalizing  change.  For  example,  the  differences  in  accounting  approach 
to  support  decentralization  versus  the  one  in  use  that  supported  centralized  accounting  presented 
challenges  at  the  agency  level  because  of  the  way  the  new  approach  cut  across  the  boundaries  of 
institutions  whose  systems  were  normally  kept  separate.  In  effect,  the  existing  governance  frame¬ 
work  determined  levels  of  clinical  activity  centrally.  Although  the  pathfinder  projects  established 
that  the  system-of-systems  cost  would  be  lower  if  governance  were  decentralized  and  aligned  to 
managing  the  through-life  costs  of  patients’  conditions,15  the  funding  agency  was  not  (yet)  in  a 
position  to  implement  these  changes. 


The  U.  S.  Institute  of  Medicine  established  the  same  potential  outcome  [USIM  2001], 
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Table  7:  Summary  of  Providing  Chronic  Care  Engagement  (Three-Year  Period) 


Scheduled/Executed  Activities 

SoS  Navigator  Tools  and 

Techniques 

SoS  Navigator  Framing  Process 


Understand  supply  and  demand 

Establish  the  need  for  a  clinical  approach 

Proposition  Analysis, 

basic  relationships 

to  managing  through-life  care  episodes 

Effects  Ladder, 

Collaboration  Stakeholder  Analysis 

SoS  Navigator  Learning/Transformation  Cycle 


Transform  business  model  to 
support  dynamically  responding 
to  asymmetric  demand 

Analyze  the  referral  pathways  and  the 
existing  methods  of  clinic  management 

Define  and  pilot  organizational 
and  technical  changes  needed 

Pilot  the  support  platforms,  episode  and 
referral  protocols,  and  procurement  prac¬ 
tices 

Value  Stairs  Analysis, 

Center  Push/Edge  Pull  Analysis, 
Effects  Ladder 

Support  integration  and  institu¬ 
tionalization  of  changes 

Summarize  the  economic  payoffs  and 
change  processes 

Recommend  changes  to  working  prac¬ 
tices 

4.2  EVOLVING  MILITARY  OPERATIONS 

This  case  involved  a  military  support  unit  that  was  facing  two  kinds  of  change  [Boxer  2006e]. 
First,  it  was  being  expected  to  extend  the  range  and  scope  of  its  roles  in  support  of  overseas  opera¬ 
tions;  it  now  would  interoperate  with  other  units  beyond  its  current  scope.  Second,  the  software 
engineering  on  which  the  unit  was  dependent  was  being  upgraded  to  include  a  much  higher  de¬ 
gree  of  automation.  The  client  SoS  Enterprise  was  therefore  the  military  support  unit,  and  its  ser¬ 
vice  users  were  the  military  operational  users  of  its  support  capabilities.  The  problem  as  initially 
defined  by  the  support  unit  was  to  identify  what  risks  the  automation  upgrade  posed  to  the  armed 
service’s  ability  to  sustain  its  support  capability  over  several  future  years;  in  addition,  we  were 
asked  to  recommend  approaches  to  mitigating  the  identified  risks.  Thus  the  problem  was  defined 
in  terms  of  the  relationship  to  the  systems  supplier.  The  framing  process  took  about  one  month, 
with  the  subsequent  activities  spanning  two  additional  months.  The  time  span  was  therefore  at  the 
opposite  end  of  the  spectrum  to  the  healthcare  experience  described  in  Section  4.1. 

During  the  framing  process,  we  focused  on  the  alignment  between  the  changing  nature  of  the  de¬ 
mands  on  the  unit’s  organizational  and  technical  structures.  Since  there  were  multiple  communi¬ 
ties  involved  with  acquiring,  sustaining,  and  operating  the  capabilities  supported  by  the  unit,  we 
also  examined  the  methods  of  governance.  These  methods  defined  how  the  communities  could 
cooperate  to  deliver  the  needed  technology  upgrade.  We  noted  that  there  were  no  obvious  proc¬ 
esses  for  resolving  differences  of  approach  among  these  communities.  We  saw  this  to  be  the  core 
challenge  to  their  managing  interoperability  risks  through  the  life  of  the  unit. 
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When  we  moved  into  the  leaming/transformation  cycle,  we  analyzed  more  closely  the  different 
approaches  used  among  the  communities.  We  identified  three  different  perspectives  by  which  the 
capabilities  provided  by  the  operational  unit  could  be  analyzed: 

1 .  the  physical  nature  of  the  capability 

2.  the  capability’s  role  in  supporting  decision-making 

3.  the  use  of  the  capability  to  generate  operational  effects 

We  drew  together  members  of  the  different  communities  in  workshops  that  focused  on  each  of 
these  perspectives.  We  then  modeled  their  understanding  of  the  technical  aspects  of  the  capability 
being  provided  by  the  operational  unit,  the  unit’s  economic  and  funding  drivers,  and  how  acquisi¬ 
tion  decisions  were  made. 

We  examined  the  output  of  these  workshops  to  identify  the  major  structural  gaps  in  the  alignment 
among  the  different  parts  of  the  operational  unit.  The  analysis  related  these  gaps  to  the  double 
challenge:  the  way  the  operational  unit  was  managing  its  different  communities  and  the  opera¬ 
tional  demands  being  placed  on  them.  These  gaps  reflected  the  fact  that  the  particular  interopera¬ 
bility  risks  identified  were  failing  to  be  addressed.  We  concluded  that,  in  order  to  bridge  this  gap, 
the  operational  unit  needed  to  embrace  a  more  adaptive  approach  that  would 

1 .  manage  the  linkages  between  needed  architectural  changes  and  the  overall  costs  of  the  capa¬ 
bility  provided  by  the  operational  unit 

2.  require  fuller  analysis  of  the  changing  mission  environment  that  the  unit  was  expected  to 
support 

Fuller  analysis  would  then  provide  a  basis  from  which  to  select  mitigation  strategies  for  the  inter¬ 
operability  risks  emerging  from  the  changing  mission  environment.  Our  part  in  the  study  con¬ 
cluded  after  delivering  the  recommendations. 

Table  8:  Summary  of  Evolving  Military  Operations  Engagement  (Three-Month  Period) 


Scheduled/Executed  Activities 

SoS  Navigator  Tools  and 

Techniques 

SoS  Navigator  Framing  Process 


Understand  supply  and  de- 

Establish  the  current  and  through-life 

Influence  Map  Analysis, 

mand  basic  relationships 

support  challenges  facing  the  operational 

Congruence  Analysis,  PAN  models, 

capability 

Interoperability  Risk  Analysis 

SoS  Navigator  Learning/Transformation  Cycle 


Transform  business  model  to 

Analyze  the  technological,  organizational, 

support  dynamically  respond- 

and  demand  characteristics  of  sustain- 

ing  to  asymmetric  demand 

ment 

Define  and  pilot  organizational 
and  technical  changes  needed 

Analyze  the  interoperability  risks  to  sus¬ 
tainment  and  proposing  mitigation  strate¬ 
gies 

[Our  part  in  the  study  ended  after 
we  delivered  recommendations 
following  the  framing  process] 

Support  integration  and  institu- 

Recommend  fuller  follow-up  on  through- 

tionalization  of  changes 

life  economics,  engineering,  and  demand 
variety 
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4.3  ADDRESSING  MASSIVE  CONTEXT  CHANGES 


The  initial  problem  in  this  case  was  expressed  in  terms  of  the  information  and  technological  sup¬ 
port  needed  for  managing  local  and  regional  wildland  ecosystems.  The  client  organization  was  an 
agency  whose  task  was  to  enable  local  communities  to  manage  and  mitigate  risks  to  life,  property, 
and  local  economies  related  to  the  emerging  characteristics  of  these  ecosystems.  To  do  so,  these 
local  communities  needed  access  to  service  providers  that  could  make  available  a  comprehensive 
risk  analysis  and  management  service,  supported  by  a  large  collection  of  tools  and  technologies. 
Multiple  organizations  were  tasked  with  providing  this  service,  a  situation  made  more  difficult  by 
the  dynamic  nature  of  the  ecosystems  (e.g.,  many  are  under  pressure  from  population  movement 
and  climate  change).  These  service  providers  varied  from  being  departments  of  national  agencies 
to  local  collaborations  funded  directly  by  grants.  The  SoS  enterprise  was  this  community  of  ser¬ 
vice  providers.  Their  systems  suppliers  were  the  providers  of  tools  and  technologies,  and  the  ser¬ 
vice  users  were  ultimately  the  local  communities  at  risk.  The  client  agency  was  expected  to  reflect 
the  interests  of  this  range  of  stakeholders  in  the  larger  task  of  managing  and  mitigating  risks. 

As  part  of  the  framing  process,  we  examined  several  elements  of  the  overall  situation,  most  nota¬ 
bly  the  existing  governance  models  and  the  types  of  demand  being  presented  by  the  ecosystems 
within  the  management  purview  of  different  service  providers.  We  saw  that  a  significant  gap  had 
opened  between  the  organizations  supplying  information  and  technological  support  (the  systems 
suppliers)  and  the  ways  this  support  could  be  orchestrated  and  synchronized  by  the  service  pro¬ 
viders  “at  the  edge”  of  the  enterprise  in  response  to  the  varying  needs  of  local  communities. 

One  solution  suggested  by  the  client  agency  was  that  this  gap  could  be  filled  by  a  common  model 
of  all  the  supporting  tools  and  technologies.  However,  our  analysis  suggested  that  such  a  model 
would  be  insufficient  to  fill  the  gap  because  of  the  dynamic  variability  and  complexity  of  the  ac¬ 
tual  demands  being  encountered  in  the  field.  We  therefore  focused  on  identifying  and  characteriz¬ 
ing  the  patterns  in  the  varieties  of  demand  and  the  changes  needed  in  the  service  providers  to  sup¬ 
port  this  variety:  the  collaboration  processes,  the  technical  architectures  needed  to  support 
distributed  collaboration,  and  the  engineering  of  the  tools  and  techniques  that  supported  service 
providers. 

We  perceived  a  difficulty  in  being  able  to  align  the  needs  of  service  providers  (many  of  whom 
understood  the  real  complexities  of  risks  being  generated  by  the  local  ecosystems  they  were  pro¬ 
viding  services  to)  and  the  supporting  tool  providers  (who  were  oriented  more  towards  developing 
a  single  unified  model  of  tool  support).  A  preliminary  report  identified  this  imbalance,  and  de¬ 
scribed  the  extent  of  this  needed  change  in  approach  and  its  practical  implications.  A  deeper 
analysis  of  the  organizational  structures  of  responsibility  and  accountability  and  their  associated 
economics  was  a  topic  for  a  subsequent  cycle,  since  an  analysis  of  the  economics  would  necessar¬ 
ily  be  the  main  driver  of  any  beneficial  change  in  approach. 
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The  client  agency  accepted  that  the  environment  the  service  providers  faced  was  one  in  which 
demand  was  asymmetric,  and  given  the  scale  of  the  conceptual  shift  that  acceptance  implied,  this 
outcome  was  appropriate.  However,  in  this  case  the  client  agency  determined  that  their  role  in  the 
overall  situation  was  one  of  more  limited  influence  than  was  appropriate  to  effecting  the  scope  of 
changes  needed  The  study  was  concluded  at  this  point.  So  in  this  case,  the  framing  process  was 
as  far  as  the  client  agency  went  with  the  SoS  Navigator  approach. 

Table  9:  Summary  of  Addressing  Massive  Context  Shift  Engagement  (Nine-Month  Period) 


Scheduled/Executed  Activities  SoS  Navigator  Tools  and  Techniques 


SoS  Navigator  Framing  Process 

Understand  sup- 

•  Initial  analysis  establishing  user/developer 

Asset  Analysis, 

ply  and  demand 

gaps  and  extent  of  tools  and  technologies 

Congruence  Analysis, 

basic  relation- 

fragmentation 

Center  Push/Edge  Pull  Analysis, 

ships 

•  Interviews  and  workshops  establishing 
extent  of  data  fusion  challenges  in  forming 
mitigation  strategies.  Organization  and 
technical  structure  and  process  gaps  iden¬ 
tified 

Scenario  Analysis 
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5  Plans  for  Future  Work 


SoS  Navigator  processes,  tools,  models,  and  techniques  evolve  as  we  work  with  client  organiza¬ 
tions  facing  different  systems-of-systems  challenges.  We  expect  our  work  to  take  us  in  these  di¬ 
rections: 

•  evolving  and  clarifying  SoS  Navigator  processes,  tools,  and  techniques,  so  that  we  can  transi¬ 
tion  them  widely 

Some  SoS  Navigator  processes,  tools,  and  techniques  have  been  heavily  used  in  certain  con¬ 
texts  (e.g.,  healthcare  or  military)  and  require  evolution  into  more  general  forms.  Others  rely 
on  specialist  language  that  makes  them  less  accessible  to  the  community  to  which  ISIS  re¬ 
sponds.  A  particular  area  of  interest  is  exploiting  the  richness  of  the  PAN  technology,  a  set  of 
techniques  and  modeling  approaches  that  can  account  for  demand-driven  interoperability  rela¬ 
tionships  between  aspects  of  an  enterprise,  and  similarly  robust  tools. 

•  exploring  and  refining  the  concepts  that  underpin  the  SoS  Navigator  approach,  so  that  we 
can  better  understand  the  variety  of  demands  to  which  it  can  effectively  respond 

SoS  Navigator  concepts  derive  from  a  wide  variety  of  intellectual  disciplines  and  influences. 
Some  of  the  concepts  described  in  this  technical  note  (see  Section  2)  deserve  further  explora¬ 
tion  and  refinement  to  ensure  that  we  understand  the  boundaries  of  their  utility. 

In  pursuing  both  of  these  paths,  we  will  derive  benefit  from  a  combination  of  collaborative  pilot¬ 
ing  and  reflective  synthesis.  Through  piloting,  we  will  gain  more  real-world  information  about  the 
usefulness,  effectiveness,  and  adaptability  of  tools,  techniques,  and  models;  we  will  also  gain  in¬ 
sight  into  nuances  about  our  processes.  Between  engagements,  we  will  codify  what  we  have  ob¬ 
served  and  learned,  modifying  our  SoS  Navigator  approach  as  needed,  as  well  as  identifying  new 
techniques  that  are  needed.  The  pace  of  progress  toward  a  state  where  the  approach  can  be  readily 
transitioned  will  be  determined  in  large  part  by  the  opportunities  we  find  for  balancing  these  two 
important  activities. 
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6  Conclusion 


Organizations  in  government  and  industry  are  moving  inexorably  toward  greater  development, 
evolution,  and  use  of  complex  systems  of  systems.  The  SoS  Navigator  approach  can  provide 
technical  and  organizational  leaders  with  insight  into  the  characteristics  and  behavior  of  the  sys¬ 
tems  of  systems  they  rely  upon. 

In  this  technical  note,  we  have  discussed  several  related  concepts  of  the  SoS  Navigator  approach 
that  are  fundamental  to  comprehending  these  systems. 

•  The  SoS  enterprise  includes  all  the  socio-technical  elements  that  are  on  the  provider  side  of 
the  purchaser-provider  boundary  in  complex  systems  of  systems. 

•  Satisfying  an  asymmetric  demand  is  an  ongoing  process  of  continually  changing  responses 
answering  dynamically  evolving,  unpredictable  demands. 

•  The  gap  between  demand  and  supply  is  evident  in  the  disconnection  between  systems  suppli¬ 
ers  and  the  users  who  daily  make  decisions  about  how  they  will  perform  their  jobs  on  the  de¬ 
mand-side. 

•  There  are  dynamically  changing  demand  situations  that  drive  required  agility. 

•  It  is  necessary  to  cross  the  boundaries  of  the  governance  structures  of  multiple  enterprises  to 
respond  appropriately  to  asymmetric  demand. 

•  There  must  be  some  balancing  force  in  place  that  maintains  a  dynamic  form  of  governance 
throughout  the  SoS  enterprise. 

•  Flexibility  and  adaptability  are  needed  to  dynamically  orchestrate  and  synchronize  solutions 
in  response  to  edge-driven  demands. 

The  SoS  Navigator  approach  builds  on  those  concepts  with  processes  to  frame  the  context  of  cli¬ 
ent  organizations  in  relationship  to  the  notion  of  the  SoS  enterprise  and  take  steps  to  adopt  new 
business  models  as  needed.  Each  process  involves  several  diagnostic  and  analytic  techniques  that 
allow  us  to  expand  our  understanding  of  supply  and  demand  and  their  relationship  to  each  other. 

We  have  begun  to  codify  and  generalize  techniques  to  support  SoS  Navigator,  after  using  them  in 
consulting  contexts  such  as  the  ones  profiled  in  Section  4.  The  version  of  SoS  Navigator  de¬ 
scribed  in  this  technical  note  focuses  on  the  tools  and  techniques  that  support  moving  toward  a 
systems-of-systems  context  of  distributed  collaboration  responding  to  asymmetric  demand.  Future 
technical  notes  will  expand  the  detail,  scope,  and  use  of  the  SoS  Navigator  approach. 
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Appendix 


Evolution  between  SoS  Navigator  1.0  and  2.0 


The  purpose  and  goals  for  SoS  Navigator  have  remained  the  same  as  SoS  Navigator  version  1.0 
has  evolved  into  version  2.0.  The  conceptual  elements  have  also  remained  constant,  although  ter¬ 
minology  has  changed.  SoS  Navigator  version  1.0  established  the  need  and  a  conceptual  skeleton. 
SoS  Navigator  version  2.0  now  adds  various  organs  and  connective  tissue. 

The  stated  purpose  for  SoS  Navigator  1.0  was  to  help  organizations  chart  a  path  through  a  system- 
of-systems  environment  by  providing  tools  and  techniques  to  characterize  organizational,  techni¬ 
cal,  and  operational  enablers  and  barriers  to  success,  identify  improvement  strategies,  and  pilot 
and  institutionalize  these  strategies.  SoS  Navigator  version  2.0  continues  these  goals  with  one  key 
refinement.  SoS  Navigator  version  2.0  focuses  on  the  more  complex  systems-of-systems  situa¬ 
tions  where  there  is  a  need  for  distributed  collaboration  in  an  environment  of  highly  variable  de¬ 
mand. 

SoS  Navigator  versionl.O  was  composed  of  three  key  elements: 

1 .  a  conceptual  framework  to  codify  core  paradigms,  concepts,  and  principles 

2.  processes,  tools,  and  techniques  to  chart  where  a  systems-of-systems  environment  is  and 
where  it  needs  to  go 

3.  processes,  tools,  and  techniques  to  improve  organizations  within  a  systems-of-systems  con¬ 
text 

In  addition  to  the  three  basic  elements,  the  SoS  Navigator  version  1.0  concept  was  based  on  creat¬ 
ing  an  internal  consistency  between  the  framework  providing  the  core  foundation  and  the  proc¬ 
esses,  tools,  and  techniques  for  charting  and  improving.  The  initial  set  of  concepts,  processes, 
tools,  and  techniques  was  used  in  several  customer  engagements  to  validate  the  general  approach. 

SoS  Navigator  2.0  introduces  significant  improvements  to  the  implementation  of  the  original  key 
elements,  while  retaining  the  three  key  elements  and  their  internal  consistency.  SoS  Navigator  2.0 
retains  the  conceptual  framework  and  reconstitutes  the  chart  and  improve  elements  into  a  framing 
process  and  leaming/transformation  cycle,  as  follows: 

•  the  framing  process,  with  associated  diagnostic  techniques,  allows  understanding  and  charac¬ 
terization  of  the  relevant  participants  and  determines  whether  the  SoS  enterprise  needs  to  re¬ 
spond  to  highly  variable  demand  situations 

•  the  continuous  learning/transformation  cycle,  with  additional  analytical  and  organizational 
change  techniques,  allows  transformation  of  the  business  model  of  the  SoS  enterprise  and 
supports  associated  technical  and  organizational  changes 

SoS  Navigator  version  2.0  provides  a  richer  set  of  fundamental  concepts  and  principles.  The  new 
diagnostic  and  analytical  techniques  which  support  the  framing  process  and  learn¬ 
ing/transformation  cycle  provide  a  deeper  understanding  of  the  elements  and  their  relationships  in 
an  SoS  enterprise.  The  SoS  Navigator  version  2.0  fundamental  concepts,  processes,  and  tech¬ 
niques  have  been  used  on  a  broad  spectrum  of  SoS  enterprises,  providing  significant  non-intuitive 
insights  (some  of  which  are  summarized  in  this  report). 
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